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INTRODUCTION 


Systems engineering is a recognized factor in aerospace system 
development both as a practical approach and an objective for de- 
velopment of large and complex systems. The technology that makes 
up systems engineering has been difficult to describe because it 
addresses many aspects of engineering operations and the process 
of development itself. This study addresses the subject in terms 
of functional activities that are performed by engineering organi- 
zational elements involved in development operations, and examines 
the systems engineering problem from the point of view of techni- 
cal parameter relationships in development of a large system; no 
attempt has been made to cover in scope or depth all aspects of 
this technology. 
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SUMMARY 


A. This study examines systems engineering in terms of functional 

activities that are performed in the conduct of a system defini- 
tion/design, and describes system development in a parametric 
analysis that combines functions, performance, and design vari- 
ables. 

The description of the functional activities that constitute sys- 
tems engineering was addressed from the point of view that as a 
meaningful technology in the development of complex systems, sys- 
tems engineering must be described as a discipline. Emphasis was 
placed on identification of activities performed by design organi- 
zations, design specialty groups, as well as a central systems 
engineering organizational element. Identification of specific 
roles and responsibilities for "doing" functions, and monitoring 
and controlling activities within the system development opera- 
tion were emphasized. 

The description of systems engineering functional activities and 
their interactions was directed to: 

1) systems engineering functions versus system elements; 

2) systems engineering functions versus phases of development; 

3) the composite of items 1 and 2. 

These treatments were found necessary because interaction of three 
correlated variables can only be described coherently by super- 
position. 

The complexity of systems engineering is compounded by organiza- 
tional as well as hardware and software complexity. In this study 
it was found that the description of the activities applied equally 
well for the case of one or many organizations; that the hierachy 
functional elements of systems engineering was the same at any 
level. In the application of systems engineering for a system 
project organization, each contractor and agency involved in the 
development is the same, and the interrelationships of these sys- 
tems engineering disciplines make up an integrated set of activi- 
ties aimed at achieving a complete and integrated system that best 
meets the mission requirements at minimum cost. 
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B. Development of parametric relationships among technical parameters 

Is an approach to describing a complex system in a logic network 
display that gives visibility to the primary parameters of concern 
in controlling development of a complex system. 

In this study a scheme was developed based on starting the logic 
networks from the primary development and mission factors that are 
of primary concern in an aerospace system. This approach required 
identification of the primary states (design, design verification, 
premission activity, mission, postmission) , identification of the 
attributes within each state (performance capability, survival, 
evaluation, operation, etc), and then developing the generic re- 
lationships of variables for each branch. To illustrate this con- 
cept, an example system was used that involved a launch vehicle 
and payload for an Earth orbit mission. Examination showed that 
this example was sufficient to illustrate the concept; a more com- 
plicated mission would follow the same approach with more exten- 
sive sets of generic trees and more correlation points between 
branches . 

This study showed that in each system state (production, test, 
and use) , a logic could be developed to order and classify the 
parameters involved in translation from general requirements to 
specific requirements for system elements. 

The technique of graphical description of technical parameter 
relationships was found to have limitations as a result of the 
huge degree of correlation that exists among parameters of a com- 
plex system. Technical parameter trees developed for the refer- 
ence system show examples of these limitations. A more sophisti- 
cated method of determining and showing parameter relationships 
is needed. 


C. The third study task is a description and explanation of the op- 

erational availability parameter. In this task the fundamental 
mathematical basiB for operational availability is developed and 
its relationship as a part of system's effectiveness is described. 
Research in this area revealed that application of operational 
availability as a system parameter varied widely depending on the 
type of time-critical requirements of the system. Several appli- 
cations of operational availability to the aerospace system were 
Illustrated to show how the parameter is applied. Emphasis is 
placed on need for a balanced analytical and pragmatic treatment 
in the system design process, and tailoring the analysis to best 
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serve each particular problem. Research Into the subject showed 
that past programs tended to overemphasize either the analytical 
or practical aspects of dealing with operational availability. 

The result was either a highly analytical "numbers game" that had 
little credibility, or an overt pragmatic "brute force" approach 
that tended to overkill or yielded no confidence in being system- 
effective. 


I. 


PURPOSE AND SCOPE 


The purpose of this study task is to describe the functional ac- 
tivities that collectively constitute the systems engineering 
technology and discipline required on major aerospace system de- 
velopment programs. 

The scope of this document includes systems engineering actions 
within the definition and design phases of the system development 
life cycle, and covers the functions of the central systems engi- 
neering organizational element as well as systems engineering 
activities performed by other design disciplines. 


II. DEFINITIONS 


System A combination of elements that work together 

to perform a preconceived mission 

System Element Fundamental building blocks that comprise a 

system, e.g., equipments, facilities, skilled 
personnel, and procedural data 

Program Phase Designation for an increment of a system de- 

velopment used for program control (This term 
is employed in conjunction with planned base- 
line management of a system development activ- 
ity.) 


Development Phase Designation of the stages that any system or 

element of a system goes through in its life 
cycle, i.e., concept definition and design 
development production (The program phases 
may be correlated with the development phase 
of a system although this is not always the 
case .) 
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Design 


Subsystem 


End Item 


Criteria 


Activity performed by engineering and scien- 
tific skills that transforms requirements into 
descriptions of equipments, facilities, person- 
nel subsystems, and procedures to implement the 
system requirements (Design as a generic term 
encompasses requirements definition concept, 
design configuration definition, designs, pre- 
liminary and final detail design.) 

A combination of things that make up a major 
system element that performs a distinct and 
identifiable function (This is not intended 
as a general definition of the term.) 

Arbitrary designation for portions of a system/ 
equipment for the purpose of system development 
procurement 

Standards or ground rules established prior to 
specification preparation that determines re- 
quirements for specification and hardware de- 
velopment 


III. SYSTEMS ENGINEERING TECHNOLOGY 


Systems engineering, as a technology, is the collective set of 
methods, procedures, scientific and engineering skills applied 
to large and complex system developments to achieve efficient and 
accurate translation of fundamental mission objectives into a sys- 
tem that best meets the objectives at minimum cost within the 
required schedule and at minimum risk. The objectives of this 
engineering technology are to: 

1) Assure that the definition of the system or equipment item, 
to satisfy an established NASA need, are conducted on a total 
system basis, reflecting hardware, facilities, personnel data, 
computer programs, and support requirements to achieve required 
effectiveness at minimum life cycle cost within the required 
schedule, and at minimum risk; 

2) Assure that the engineering effort is fully integrated, so 
that it reflects adequate and timely consideration of design, 
test and demonstration, production, operation, and support 

of the system/equipment ; 
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3) Integrate the design requirements and related efforts of re- 
liability, maintainability, integrated logistics support, human 
factors engineering, safety, and other engineering specialities 
with respect to each other as well as into the mainstream of 
the engineering effort; 

4) Assure compatibility of all interfaces within the system, in- 
cluding necessary supporting equipment and facilities; and to 
assure the compatibility and proper interface of the system 
with other systems and equipment that will be present in the 
operational environment; 

5) Provide means to establish and control the Work Breakdown 
Structure (WBS) throughout the life of the system/project; 

6) Provide means for evaluation of changes that will reflect 
consideration of the effect of change on overall system per- 
formance and effectiveness, schedule, and cost, and assure 
that all affected activities participate in the evaluation 
of changes; 

7) Provide a framework of coherent system requirements to serve 

as source data for development plans, contract work statements, 
specifications, test plans, design drawings, and other engi- 
neering documentation; 

8) Provide visibility to measure and judge technical performance 
status for timely identification of problems; 

9) Provide, during the course of the program, requirements for 
making major technical decisions that optimize the total sys- 
tem to best meet the mission objectives. 

Systems engineering is the functional element within the engineer- 
ing process that applies scientific, engineering, and management 
techniques to accomplish these objectives. 

The implementation of activities to fulfill these objectives is 
achieved in each phase of the system development cycle by a spe- 
cific set of functional activities of a systems engineering dis- 
cipline within the system project organization. The systems engi- 
neering discipline performs its function with specific roles and 
responsibilities that relate to other technical disciplines and 
to project management. 
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The problem of achieving these objectives results from the com- 
plexity of types of system elements, numbers of specialists, and 
numbers of organizations (contractors and agencies) involved in 
a system development. This complex problem is represented in 
Figure 1 which illustrates the following variables that must be 
addressed: 

1) Evolution of system elements in time; 

2) Interrelationship of system elements; 

3) Interrelationship of disciplines and organizations of disci- 
plines in each system element definition and design. 

For this reason, the systems engineering technology, and the dis- 
cipline that implements it, is concerned with the process employed 
to achieve an orderly evolution of the system, and with positive 
actions within the process to force the definition and design of 
the best possible system. This process and the functional activ- 
ities of the system engineering discipline are identified and 
described in the following section. 
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IV. 


SYSTEMS ENGINEERING PROCESS 


The Development Cycle 

The system development cycle is fundamentally the same whether 
the system to be developed is a complex aerospace system or a 
single system element. The development' cycle is made up of three 
major phases of activity — concept, definition, and design. 

These phases are natural breakdowns resulting from steps that 
must be made in transforming an objective into a system of ele- 
ments. These phases form the basis for the strategy used for 
program control as covered in NPD7121.1 which establishes the 
policy for phased project planning. 

Within these phases of development, the systems engineering func- 
tional activities constitute the means used to force and maintain 
a consistent, complete, and accurate transformation of mission 
objectives into a system design. 

The concept phase normally consists of analyzing the mission or 
scientific objective in sufficient detail to develop concepts of 
implementation. The products of this phase of activity are feasi- 
bility analyses, system requirements documentations or specifica- 
tions, and first-order system development schedules and costs. 

The definition phase consists of the detail definition of the 
total system including flight hardware, support equipment, soft- 
ware, personnel, etc. The products of this phase of activity 
are complete operational use definitions, trade studies, config- 
uration descriptions and preliminary specifications, and plans 
for the development and use of the system. The design phase con- 
sists of the detail design and fabrication of each system element, 
evaluation of the system through analysis and test, activation 
of the system, and all other activities required to support and 
use the system. 

Within these development phases, the achievement of desired results 
is a function of how the overall development process is conducted 
and positive measures taken within the process to give order to 
and control the diverse activities of design disciplines. 

The system engineering process is a formalized method for planned 
and scheduled solution of large, complex engineering development 
design problems. It is based on the scientific method that was 
developed for solving problems in the physical sciences. This 
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method comprises recognition of the problem, postulating a solution, 
and then verifying the solution. By extending the scientific meth- 
od into the domain of technology, a logical process was evolved 
that enables quicker and more cost-effective solutions to design 
problems that would ordinarily require several years to resolve. 

For the design of an aerospace system, the system engineering pro- 
cess has expanded on the scientific method and extended its use 
of all aspects of the program. It is used from mission definition 
through identification of systems performance requirements, design 
requirements, proposed design solutions, layouts, detailed design, 
development testing, production, checkout, flight qualification, 
and mission operation. 

The process consists of three steps. Each step is used continu- 
ously during the program, first on the initial design and subse- 
quently on all changes to that design. The three steps are (1) 
definition of requirement, (2) integration of subsystem design, 
and (3) verification of subsystem performance to the design re- 
quirements . 

The objective of this process is to produce a system design that 
will satisfy all mission requirements with a minimum expenditure 
of program resources. 

The first step of the system engineering process occurs in the 
concept phase. The feasibility of the object mission is determined 
and the fundamental system concept is selected. In the definition 
phase of the system engineering process, the object mission is 
specified, and, from It, mission objectives and system performance 
requirements are derived. The Statement of Work (SOW) incorporates 
these requirements and further identifies performance requirements 
for all subsystems. These requirements are defined in a mission/ 
system requirements document. Design requirements based on re- 
liability, environment, safety, service life, and other consider- 
ations are identified in an environmental and design requirements 
document . 

Ground support equipment (GSE) requirements for the system evolve 
in a similar manner, originating from mis si on/ system requirements. 

Requirements that must be considered in the overall system design 
may be grouped into three major areas which are performance, de- 
sign, and test. Within each of the major areas a representative 
list of requirements may be tabulated. This tabulation, in the 
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form of a list, has been compiled and is given in Table 1. From 
the length of this list it can be seen that the definition of all 
requirements that constrain the system design cannot be completed 
prior to initial design release and, therefore, a design change 
system is required to revise released drawings and specifications. 
It will also be noted that because of the low level of requirements 
shown, such as performance requirements at the component level, 
not all requirements can be known initially. These requirements 
evolve as the design progresses. 

Systems analysis of all the requirements illustrated by Table 1 
results in the second step of the systems engineering process. 
Tradeoff study reports that identify alternative mechanizations, 
satisfy the requirements, and select the best design are performed. 
These reports also describe how the system was sized, the perfor- 
mance envelope of the complete system in its operating environment 
under all static and dynamic variations of external inputs and 
internal system tolerances, critical interactions with or depen- 
dence upon other systems or structures, safety precautions, pro- 
visions for reliability, producibility , and maintainability 
system growth considerations, and unusual human factors aspects 
in the design. The results of these analyses culminate in a con- 
figuration baseline that is the first definition of a complete 
system configuration. Design layouts, specification control 
drawings, process specifications, and procurement specifications 
proceed from this document to define the configuration exactly 
and govern its procurement, manufacture, assembly, test, and 
checkout throughout the design, development, and production pro- 
cess . 

As the design takes specific form, the requirements documents 
progressively "harden" to the form of performance, design, and 
test requirements for the hardware. These are incorporated in 
system, system element and subsystem specifications that describe 
specific design and verification requirements for the detail de- 
sign of the system (Part I). Part II of these specifications is 
the documented solution to the Part I specification. The solu- 
tion originates during the design of system elements and specifies 
product configuration, and all verification, preparation for ship- 
ment, and use instructions. 

A similar hardening of requirements occurs simultaneously with GSE 
and culminates in a ground system specifications, GSE and item 
specification, and support equipment specifications. 
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Table 1 Typical Requirements for Aerospace Systems 


1 . PERFORMANCE REQUIREMENTS 

II. DESIGN REQUIREMENTS 

III. TEST REQUIRKHTNl'- 

a. system 

Mission Objectives 
Mandatory 
Desired 

Mission Profile 
Normal (reference) 

Alternative 

Abort 

Mission Trajectory 
Position 
Attitude 
Velocity 
Acceleration 

Payload 

Crew 

Timelin* 

Environment 

Natural 

Induced 

Interfacing Vehicles 

8. SYSTEM ELEMENTS 

Primary Functions 
Alternative Functions 
Emergency Functions 
Duty Cycles 

Tolerances and Error Budgets 
Interfacing Systems end Subsystems 
Inputs 
Outputs 
OSE 

Facility 

Associate Contractor 

on 

C. COMPONENTS 

Primary Functions 
Alternative Functions 
Emergency Functions 
Ducy Cycles 
Power Consumption 
Switching and Sequencing Logic 
Environment 
Cooling and Heating 
Lubrication 
Consumab les 
Solid* 

Liquid* 

Cass* 

Tolerances and Drift Bates 
Size, Shape, Location 
Hass, e.g., Moments of Inertia 
Loads 
Static 
Dynaaiic 

Acceleration 

Vibration 

Acoustic 

Shock 

Failure Bate 
Safety Margin 
Useful Life 
Aging 
Humidity 
Radiation 

Electromagnetic 
Radio Frequency 
Nuclear 

Biological and Chemical 
Life Support 
Human Performance 
Moisture and Fungus 
Contamination 
Corrosion 
Cleanliness 

Safety 

Ground 

Flight 

Personnel 

Equipment 

Performance Growth Capability 
Interfacing Components 
Mechanical 
Electrical 
Fluid 

Structural 

Environmental 

Radiation 

A. DESIGN AND DEVELOPMENT 

Contract Specif ications 
Design Standards 

Government Specif icstions 
Standards Drawings 
Drawing Requirements Manual 
Design Manual 
Material Manual 

Identification and Narking Manual 
Standard Shapes Manual 
Electrical/Electronic Manual 
Fluid Systems Manual 
Mechanical Parts Manual 
Structures Manual 

Master Dimension Specification Manual 
Deslgu Cost Guide 

System Safety Design Standard Manual 
System Safety Operations Standards Manual 
Standard Practice 

Legal 

Security 

Codas 

Civil 

Structural 

Architectural 

Mockup Inspection Results 

Management Reviews 
Design Reviews 
PRR 
PDR 
CDR 
FRR 

B. PRODUCTION 

Program Schedules 
Program Coats 
Producibility 
Manufacture 

Assembly 

Installation 

Interchangeability 

Workmanship 

Identification and Marking 
Acceptance Teat Results 
Systems Servicing 
Systems Checkout 
Individual 
Combined 

C. MISSION SUPPORT 

Logistics 

Sparing 

Maintainability 

Maintenance 

Maintenance Repair Cycle 
Service and Access 

Rap lace ability 
Ground 
Inflight 

Transportablll ty 
Preservation 
Packaging 
Packing 
Handling 
Shipment 
Storage 

Orbital Support 

D pari AinirH TNSPrmnN tkst hi , hits 

Environsmntal 
Leak and Functional 
Static Firing 
Electrical Mating 
Flight Readiness 
Countdown Demonstration 

E. FLIGHT TEST RESULTS 

F. POSTPLIGHT INSPECTION RESULTS 

A . TEST 

Test Plan 
Test Procedure 
Test Objectives 
Teat Purpose 
Configuration 
Simulation 
Measurements 
Accuracy 

Statistical Design 
Criteria for Success 
Criteria for Failure 

Teat Results 
Breadboards 
Prototypes 
Verif ication 
Major Ground Development 
Structural 
Environmental 
Propulsion 

Major Flight Development 
Launch Environment 
Orbltel 

Atmospheric Entry 
Recovery 

j 
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Requirements reviews follow requirements definition for all systems 
and facilities and they initiate Phase II, the integration phase 
of system engineering. These reviews use standard operations anal- 
ysis techniques to fly the mission on paper using the proposed de- 
signs and computer simulations of the nominal and abort trajecto- 
ries to determine mission success and crew safety probabilities, 
to verify system compatibility with mission objectives, and to 
improve the total design. Simultaneously with the reviews, inte- 
gration of the design proceeds as integrated schematics are com- 
pleted to assure continuity, compatibility, and responsibility 
of subsystem-subsystem interfaces, subsystem-GSE interfaces, and 
GSE-facility interfaces. 

When approximately 10% of the basic detail design process has been 
completed, the preliminary design review (PDR) is held. This is 
an assessment of the preliminary design of all flight, ground, and 
test site subsystems for compatibility with mission objectives, 
and is a continuation of the integration phase begun with the 
requirement reviews. Before completion of production drawing and 
design specification release, a critical design review (CDR) of 
all flight and ground hardware is completed. The purpose of this 
review is the same as for the PDR except that it is more thorough, 
particularly insofar as equipment interfaces are concerned, since 
much more data are available. After the action items have been 
worked, the basic release is completed. 

The third step of the system engineering process commences with 
verification analysis studies and continues through all subsequent 
testing including development, qualification, acceptance, checkout 
and mission operations. Performance verification for all components 
and subsystems is achieved through analysis of test. Verification 
results permit a technical performance evaluation of the design 
and, if the results are favorable, increasing confidence in the 
reliability of the equipment. Verification is achieved by compar- 
ing results with specification requirements. 

Through a continuous iteration of systems engineering phases — re- 
quirements, integration, and verification — an effective design 
will be produced with a minimum cost and time expenditure. Require- 
ments are documented and traceable to the design for use at reviews 
and for evaluation of proposed changes . Technical progress of the 
development is monitored, assessed, and displayed to give precise 
status of progress and to pinpoint areas that require additional 
resources to improve progress. 
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These process activities must be reflected in specific functional 
activities in each phase of development. They can be categorized 
as analytical, integration and engineering actions in each phase 
of system development. The aggregate of these functional activ- 
ities constitutes the systems engineering disciplines roles and 
responsibilities . 
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V. 


SYSTEMS ENGINEERING DISCIPLINE 


The systems engineering discipline is the technical organizational 
element that provides the skilled resources, methods, and proce- 
dures to achieve complete and optimum system objectives with the 
resources available. The functions, roles, and responsibilities 
fall into two categories: those that make up a central systems 

engineering discipline and those that fall within the technical 
discipline organizations that participate in the system develop- 
ment. These two types of systems engineering activities are shown 
in Figure 2. 



Propulsion 

Structures 
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Environmental Control 
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Mechanical Engineering 


Central Systems Engineering Groups 


Mechanical 

Communications 

Electrical 
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V Electronic 

| Engineering 
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Facility Design and Engineering 
Flight Mechanics/Aerodynamics Ballistics 




Technical Discipline Groups 
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Figure 2 Systems Engineering Organization 
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A. 


CENTRAL SYSTEMS ENGINEERING DISCIPLINE 


The objective and purpose of a central systems organization is to 
make available to development project management skilled resources, 
methods, and techniques to solve problems exhibited by complex sys- 
tems in each phase of development. The functional activities of 
this discipline are (1) those that are directed at making the tech- 
nical development process an efficient and controlled operation, 
and (2) those specific line activities within the development pro- 
cess. The first of these management activities govern and control 
the actions of all disciplines and all system elements in the tech- 
nical development of the system; the second is the requirements def- 
inition, integration, and verifications performed as a part of the 
system development. These activities and the functions that are 
performed are described in the following paragraphs. 

a. System Management Activities 

The part played by the central systems discipline in the direction 
and control of a system development is to establish the central 
requirements and constraints that govern each system element, pro- 
vide the necessary decision criteria and techniques for deciding 
between alternatives and providing the mechanism for evaluation 
of results during and at the end of the phase effort. The descrip- 
tion of these three functions follows. 

1. Baseline Control 


Within and between development phases, the systems engineering 
activity required to achieve consistent and compatible results 
is to establish control over the activities of all organizations 
and disciplines engaged in the system development. 

The fundamental approach is to establish and maintain a system of 
positive definition, documentation, and control between interfac- 
ing requirements, design requirements, and design solutions. The 
heart of this approach is the system engineering process and base- 
line management. 

Baseline management is a technique that uses uniform documentation, 
engineering reviews, and standard procedures to ensure an orderly 
transition from one major commitment point to the next in the sys- 
tem engineering process. Baselines may be established at any 
point in a program where it is necessary to define a formal depar- 
ture point for control of future changes in performance and design. 
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Systems engineering establishes the documentation complex in the 
form of specifications, interface controls, and other requirements 
data forms in each phase, and maintains them as control reference 
points during the evaluation of the design in each phase. Since 
the development of a system is an iterative process, continuing 
changes and revisions in requirements are necessary to achieve a 
balanced design that yields the most benefits. The progressive 
baselines established through the development cycle provide the 
means for assuring these revisions are made under controlled con- 
ditions. Systems engineering examines these revisions against the 
baseline for impact on the system's ability to perform the mission. 
This activity provides continuing assurance that the integrity of 
the system/mission relationship is maintained. 

2. Decision Management 

The development of complex systems in which many different and 
conflicting requirements are present requires that a means be 
provided for relating characteristics of the system in terms that 
permit them to be combined, and the value to the total system 
assessed. In each phase of the development cycle, trade studies 
are made between alternative approaches, concepts and designs with 
the objectives of selecting the candidate having the greatest 
overall benefit to the sytem, i.e., the one striking the best 
balance or compromise between all mission/system requirements and 
program constraints. Since these decisions occur within each sys- 
tem element, and are performed by the technical disciplines within 
a broad organizational complex, a consistent means in terms of 
decision criteria and methodology is required. 

Systems engineering develops the priority, ranking, and relative 
values of program, mission, and system parameters to facilitate 
selection between candidate concepts, configurations, and designs. 
In addition, guidelines are provided for the format and content 
of trade studies to assure complete treatment of each major deci- 
sion. System engineering provides assistance in the conduct of 
these decision actions and approves results of the study prior to 
project management's final approval. 

3. Technical Evaluation 


In each program phase, systems engineering performs an assessment 
of the technical results on a continuing basis and at predeter- 
mined points in the process to assure that the consistency, com- 
pleteness, and integration of all system elements is maintained. 
The objective of this activity is to find problems (performance 
and design) early enough to avoid significant cost and schedule 
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4. 


impact. This objective is accomplished by tracking the perfor- 
mance and design, and maintaining an overall system visibility 
to performance capability, design characteristics, interfaces, 
and configurations. 

Systems engineering provides tracking methods and techniques, 
and establishes reviews and review procedures to examine develop- 
ment results, identify discrepancies, and follow-up on their res- 
olution. The tracking and assessment of performance is accom- 
plished by developing and maintaining cognizance over the primary 
performance factors of the system, and comparing them to the al- 
located requirements. Reviews are accomplished by identifying 
appropriate times in the process based on critical decision points 
or program requirements for a baseline update, assembling a team 
of specialists who are knowledgeable in the design and technologies 
involved, and in performing an indepth examination and comparison 
with baseline requirements. 


Summary 


The central systems engineering provides resources for and accom- 
plishes the following system process activities during each phase 
of system development: 


1) Requirements 


a) Define specification mechanism (hierarchy of requirements 
documents to be used to implement the system definition). 

b) Compile, integrate, and issue initial requirements for 
each program phase. 

c) Perform baseline requirements management during each 
development phase . 

d) Compile results of each phase into specifications for 
the next phase activity. 

e) Develop WBS and SOW requirements. 

2) Decision Requirements 

a) Develop and provide decision criteria for combining 

mission, system, and program factors in making decisions 
between alternative approaches, concepts, and designs. 
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b) Provide standards of format and content of trade studies. 

c) Assist in performing trade studies that have significant 
system impact. 

3) Technical Evaluation 

a) Plan, organize, conduct, and follow up system design 
review . 

b) Develop techniques for and perform technical performance 
tracking . 

b . Central System Engineering Line Functional Activities 

The central systems engineering discipline is composed of five 
principal elements and one correlated element as follows: 

1) System Design and Integration 

2) System Effectiveness 

a) Reliability 

b) Maintainability 

c) System Availability 

d) System Safety 

e) Environmental Requirements 

3) System Verification 

a) Design Verification 

b) Premission Verification 

c) Mission Verification 

d) Postmission Verification 

4) Mission/Crew Operations 

5) System Performance 

6) Logistics (Correlated) 


16 


These organizational elements represent the basic system and mis- 
sion attributes desired as final results from the system develop- 
ment process • These factors have a broad effect on all system 
elements that comprise the total system. This is illustrated in 
Figure 3. As shown, these systems engineering disciplines are 
involved in all possible types of system elements. 



Figure 3 Central Systems Engineering Desoiplines /System Element Matrix 

The roles and responsibilities for functional activities of each 
of these disciplines is related to the fundamental design process 
in any system element development. Figure 4 shows this fundamental 
process together with the type of activities performed by systems 
engineering . 



Activity 

Figure 4 Fundamental design Process 
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Systems engineering provides initial design concepts and analysis, 
performs integration between system elements and finally evaluates 
the output results for compatibility , These actions are the same 
for each program phase and for all system elements. Each of the 
design disciplines, and the systems engineering activities involved 
in each, are described in the following subparagraphs. 

1. Systems Analysis and Criteria 

The initial steps in the development process for system definition 
are activities identified as systems engineering functions. These 
activities, shown in Figure 22, page 115, represent the initial 
mission, program, and systems analyses necessary to provide con- 
sistent criteria from which the definition of individual system 
elements can proceed. Central systems engineering has the lead 
role in these activities. It will be noted that among the inputs 
to these functions is the conceptual design activity of the pre- 
vious phase and the applicable study guidelines provided by the 
conceptual design activity. The first of these is the studies, 
analyses, and analytical tools developed by the study team during 
the concept study phase. The study guidelines are the directive 
data provided to all competing teams as a reference set of ground 
rules and requirements to govern the design definition. These 
data constitute initial conditions for the development problem. 

The first step is tp state the problem based on what is known, 
and to expand these initial conditions sufficiently to enable the 
development of each system element to proceed along complimentary 
lines. The subsequent development activities are highly iterative 
and the object of establishing directive criteria is to start these 
activities with guidance so as to minimize the number of itera- 
tions and assure that a common starting point is used by all spe- 
cialty groups. Many groups contribute to the development of these 
baseline requirements. The systems engineering discipline compiles 
these data and issues a requirements document that becomes direc- 
tive to all products (subsystems) and functional (vehicle perfor- 
mance, reliability, safety, logistics, etc.) disciplines. 

The content of this document is shown in the Appendix. The extent 
of these requirements is dependent on the depth of study during 
the previous phase. The approach used is to provide the best data 
possible at the start of the study and to add and revise the re- 
quirements as the definition proceeds. 
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System Performance 


In the system design and integration of a complex aerospace system, 
control and management of flight equipment performance is a major 
concern. In each type of system element (launch vehicle, space- 
craft and payloads), performance capability, together with safety, 
reliability, and availability are the primary factors in mission 
success. The objective of systems engineering is to provide the 
means for controlling, from the total system point of view, the 
system performance capability. This involves determining and 
controlling all factors that may influence system performance ca- 
pability, such as mass properties of the system, flight dynamics, 
guidance, software, etc. One major element of controlling system 
performance is managing system mass properties that are influenced 
by all flight system elements. The following is typical of how 
this is done and representative of how other areas would be con- 
trolled. 

The system performance group provides skills and methods for al- 
locating estimating, predicting, and measuring weight and other 
mass properties characteristics in all phases of development. 

Again, as in all central systems activities, the approach is estab- 
lishment of a baseline of allocated requirements, participation in 
decisions as the design evolves, and assessment of results at the 
end of each phase of compliance with requirements. 

Initially critical mass properties are defined and related to the 
vehicle system performance. They are subsequently documented in 
specification, interface, and requirements trees to be used ulti- 
mately as the primary reference for demonstration of delivered 
performance . 

This set of design requirements is then broken down by design func- 
tion and assigned to the responsible personnel for effective con- 
trol. Other forms of control involve implementing subcontractor 
weight cost incentive plans, establishing the value of a pound 
(in the performance sense) so as to influence tradeoff decisions, 
and dissemination of a timely mass properties status from which 
decisions regarding corrective action can be based. 

The analysis of mass properties characteristics begins with pre- 
liminary design criteria and a concept formulation from which a 
first weight estimate is derived. Subsequent iterations during 
design definition evolve more refined design mass properties. 
Predicting performance oriented mass properties continues through 
the design and build process with a constant awareness of their 
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effects on required system performance. The mass properties anal- 
ysis is not complete until proper allowances have been made for 
the lack of detail design, contingencies, and historically proven 
weight growth. 

Mass properties analysis data whether a first cut estimate or a 
refined analysis are accompanied by a confidence level that re- 
quires constant assessment. The control of mass properties in 
support of delivering system performance requires supporting 
analysis and historical experience developed in a timely manner 
to maximize the data confidence level. 

The data confidence level continues to improve as hardware items 
are weighed and accounted for in a prefinal assembly stages of 
development. This leads to the last stages of data development 
that include final delivered vehicle mass properties verification 
by measurement/analysis plus any required steps to accurately 
track vehicle configuration and associated mass properties up to 
flight time and on through the mission. 

To assure delivery of effective mass properties/system performance, 
several prerequisites must be recognized. First of all, consistent 
design definition and data breakdown help significantly in using 
the data. Next, program awareness and preparedness to respond to 
required design influenced by critical mass properties must have 
a high priority. Also, analytical methods and measurement equip- 
ment required to provide good data results must be consistent with 
data accuracy requirements. 

System performance will be delivered only after the close associa- 
tion of management action, thorough data acquisition, and factual 
data dissemination influence the required design decisions. 

Central systems mass properties serves as a member of the system 
performance team (flight mechanics, propulsion, guidance, etc) 
and assists in the sizing, evaluation, and trade studies in the 
synthesis of a performance/ design solution. In summary, systems 
engineering performs the following activities to control mass 
properties that affect flight vehicle performance. 

1) Initiate and maintain a system to provide a high degree of 
weight and mass properties control of flight articles. 

2) Provide critical mass properties for input to contractual 
documentation, specifications, and program control documenta- 
tion. 
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3) Establish mass properties allowances, monitor and control 
detail design weight, and assist in establishing flight 
configuration. 

4) Determine and be responsible for product weight, center of 
gravity balance, moment of inertia and product of inertia 
by using standard methods of estimation, calculation, and 
actual measurement. 

5) Maintain mass property accountability, prepare and issue 
reports reflecting program weight status and performance 
mass properties data. 

6) Supply and coordinate flight weight and mass properties 
summaries for the purpose of analyzing product performance. 

7) Determine and verify weight of components and flight (air- 
borne) articles by actual measurement. 

8) Provide field weight liaison for the purpose of flight 
configuration accountability prior to product flight. 

9) Participate in flight performance analysis and sizing, 
provide weight estimates, and develop allocations for 
system definition. 

10) Develop mass properties management plans . 

11) During definition/design perform mass properties trend 
analysis and prediction. 

12) Maintain cognizance of mass properties requirements standards. 

13) Develop and provide monitoring and control over payload 
dependent elements (stowage, consumables). 

3. System Effectiveness 

System effectiveness analysis provides the skills, methods, and 
procedures for system optimization, safety availability /dependabil- 
ity, and environmental requirements. The objective of system ef- 
fectiveness analysis is to provide means for measuring, allocating, 
and selecting designs and approaches that yield the maximum prob- 
ability of mission success, under the risks assumed. The function 
or measure that determines quantitatively the achievement of the 
optimal combination of resources is a "principal figure of merit". 
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This criteria may be in the form of cost figures, or the specifica- 
tion of technical performance characteristics. A system may have 
several principal figures of merit, and the resultant outcome combined 
to furnish one overall measure. In general, a systems effectiveness 
analysis isolates the critical accountable factors in terms of a 
value tradeoff between significant factors. The basic elements of 
a systems effectiveness analysis include: 

an assessment of the state of the art to define constraints on 
solutions limited by technology, risk, and time; 

an assessment of the critical and most sensitive design and per- 
formance parameters to determine the necessity for further 
refinements ; 

preliminary design configuration of potential and hypothetical 
alternatives ; 

design tradeoff investigations; 

system description and parameter specifications. 

Optimization - Optimization refers to attainment of the "best” com- 
bination of resources in accordance with selected criteria. It repre- 
sents an attempt to quantify the factors (measured in terms of cost, 
or technical performance) in order to select from a set of alterna- 
tives. Since a system may have associated with it multiple principal 
figures of merit, the specification of more than one analysis model 
may be required for each feasible configuration or design approach. 

For example, in a multistage decision problem, dynamic programming 
may be used to optimize the totality of overall system combinations. 
However, at each stage in the decision process, the . technique of 
maximum likelihood estimation may be used to obtain parametric data 
for use with other subsequent optimization models. In any event, 
the degree and analysis of functional areas that determine the param- 
eters to be optimized include: 

environmental factors; 

reliability and maintainability; 

support policies; 

numbers of skill levels of personnel; 
training equipment and facilities; 
logistic considerations; 
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operational modes; 

interfaces with other sys tern/ subsys terns . 

In addition, all pertinent assumptions made at each phase in the 
analysis must be stated explicitly. For example, the relationship 
between logistics and repair time, as well as the assumptions of 
failure rates and repair time, must be adequately documented, and 
the rationale and data source identified. 

Application of System Effectiveness Analysis to Engineering Design - 

Design optimization deals with application of systems effectiveness 
techniques to determine the best system configuration in terms of 
performance characteristics and cost. This involves the establish- 
ment of criteria or models for selecting among alternatives such 
that the evaluation of different missions, modes of operation, and 
system design concepts, etc can be analyzed within a common frame 
of reference. System effectiveness models are usually developed 
early in the system definition phase to provide the means for quan- 
titatively combining system performance parameters having different 
dimensions with system cost, to arrive at an overall figure of merit 
is an expression of the effectiveness of the design approach, and 
as such can be used to compare the composite attributes of one de- 
sign approach with another. System effectiveness models allow the 
input parameters to be varied individually so that their relative 
sensitivity on total system performance and life cycle costs can be 
determined. Parameters used in the effectiveness models correlate 
system functions and system elements. The optimization analysis is 
performed primarily during the system definition phase when optimi- 
zation is applied to the allocation of specific requirements, for 
performance of equipment, facilities, personnel skills, computer 
programs, and other software, in conjunction with a comprehensive 
analysis of mission, support, and operations requirements, and of 
total cost of the system. This optimization stresses consideration 
and integration of all technical disciplines such as reliability, 
maintainability, safety, etc. Expected technical performance re- 
sults are the optimized combination of contributions from all engi- 
neering specialties whose parameters are factors affecting perfor- 
mance and cost. 

The functional activities involving design optimization and system 
effectiveness investigations use the techniques and disciplines of 
systems analysis. Typically, these consist of — 
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1) Parametric Analysis Methods, 

2) Search Methods, 

3) Methods of Steepest Ascent, 

4) Game Theory, 

5) Statistical Methods, 

6) Scheduling Algorithms, 

7) Stochastic Processes, 

8) Linear Programming, 

9) Dynamic Programming, 

10) Geometric Programming, 

11) Simulation, 

12) Monte Carlo Techniques, 

13) Network Methods. 

Of these methods, Parametric Analyses as applied to the selection 
of design parameters which maximize system performance, are the most 
widely used of the various techniques in systems analysis. This is 
perhaps because these methods are the best understood and are sim- 
plest to apply. 

Generally, Parametric Analyses consist of the following steps: 

1) Define a baseline (or preliminary) design using analyses 
of system mission objectives and requirements. 

2) Develop functional relationships between system parameters 
and achievement of objectives (i.e., outage and payload in 
orbit) . 

3) Vary the system parameters one at a time over a feasible 
range and measure the effect on achievement of system 
objectives. (This is usually plotted to add visability 
and the parameter value selected at that value which max- 
imizes the achieved objectives.) 
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4) With the parameters thus selected, measure the effect of 
the combination set of parameters on total objectives 
achieved . 

The first two steps of this process are common to all approaches 
relative to selection of optimum parameters. The preliminary design 
may be based on parameter analyses of subsystems and/or components 
included in them. The preliminary design serves as a reference to 
measure changes in performance with respect to achieved objectives. 

Some obvious problems can be encountered in this process , and engin- 
eering judgments are usually exercised to avoid these. For example, 
weight, volume, and power constraints could be exceeded unless some 
prior allocation of these resources to subsystems and assemblies is 
made. Some functions will be monotonically increasing or decreasing 
over the feasible range for the design parameter; other problems 
that are not so easily solved are the interactions between such 
parameters as thermal environment and electrical power. These must 
be evaluated independently in an iteration process. 

In summary then, some of the functional activities of the design 
optimization procedure (using systems analysis methodologies pre- 
viously mentioned) are: 

1) system effectiveness analysis; 

2) availability/dependability specification; 

3) optimal policy structure for maintainability, logistics, and 
supply; 

4) development and provision of methods of cost effectiveness 
analysis; 

5) parameter sensitivity analysis; 

6) technological forecasting; 

7) risk assessment; 

8) evaluation models. 
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System Safety - System safety engineering is concerned with reducing 
hazards and failures by influencing system definition and design to 
achieve acceptable risks in each mission state. The sequence of 
events in system safety is: 

1) mission analyses and identification of hazards; 

2) definition of criteria or requirements for all system element 
definition/design; 

3) provision of safety inputs to system element trade studies; 

4) analysis of system element definition/design to determine 
compliance with requirements and to uncover hazards ; 

5) identification and follow-up on solutions (design changes or 
procedural changes) . 

To maximize safety, it is necessary to identify and minimize those 
failures that produce the unsafe condition failures. It is also 
necessary to identify the warning time associated with failure, the 
feasibility and method of detection, and the corrective action re- 
quired, particularly that which will minimize crew risk. Safety 
Analysis starts in the conceptual phase by reviewing or establishing 
mission ground rules and assumptions. A ground rule such as fail- 
operational /fail-safe versus fail-operational/ f ail-operational/ fail- 
safe has significant impact on design, operations, and cost. Mission 
ground rules are refined and updated until the equivalent of a mission 
flight plan is generated. This technique permits the systems analy- 
sis and trade studies to consider current mission planning. As 
system definition proceeds, definitive design oriented criteria are 
developed. A design safety handbook is invoked to provide a refer- 
ence to safety design criteria that can be used for evaluation of 
quantification approaches. Crew Safety Analysis is of necessity 
reiterative and the analytical technique requires assessing the im- 
pact of equipment changes throughout the life of a program. 

Crew Safety Analysis involves not only all design areas, but must 
use and understand reliability, maintainability, human factors, on- 
orbit mechanics, environmental, etc data to assure that the inherent 
crew safety is not degraded during the build, test, change cycle, 
and operational phases of a program. When the crew is identified, 
crew safety personnel become the focal point to work specific de- 
tailed requirements, simulations, changes, and procedures. 

In summary, the system safety tasks performed in the def inition/de- 
sign phases are: 
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1) Prepare system safety engineering plans. 

2) Specify general requirements documents to be used in the system 
definition/design; e.g., MIL specification, NASA documents, 
safety handbooks. 

3) Perform failure hazard effects analysis for crew/system safety. 

4) Establish hardware and software requirements for detecting safety 
significant malfunctions. 

5) Perform warning time analysis. 

6) Perform abort/escape system studies to verify system design and 
develop new design requirements . 

7) Provide design criteria for safety critical areas. 

8) Perform hazard analyses for each mission state and each system 
element. 

9) Identify range requirements and obtain waivers when necessary. 

10) Identify procedural constraints necessary to assure safety. 

11) Participate in development and use of simulators as necessary 
for safety purposes. 

12) Perform human error analysis, identify potential flight crew and 
ground command errors that can have safety impact. 

13) Participate in safety working groups. 

14) Participate in and/or conduct design reviews of hardware as 
necessary for safety. 


Avai Zabi lity/Dependabi Z-i ty - The steps involved in sizing and optimi- 
zation of availability/dependability involve a series of analyses as 
shown in Figure 5, and are aimed at sizing reliability and maintenance 
requirements that drive the mission and support system designs. The 
disciplines directly involved in these activities are reliability 
and maintainability specialists. As shown in Figure 5, availability/ 
dependability requirements result from mission analysis in which 
the mission success requirements are identified. This analysis in- 
cludes the definition of mission requirements and system configuration 
and definition of probability requirements for system definition and 
design. Operational analyses of the system and its operational 
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Mission 

Requirement 
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Figure 6 System Design Disciplines, Criteria, and Functional Clements 






concepts result in MTFB (mean time between failure) and MTTR (mean 
time to repair) requirements . These became the requirements that 
led to a reliability and maintainability policy which drives the 
mission system and support system designs. These analyses are per- 
formed by system analysis, reliability, and maintainability special- 
ists in conjunction with system design and logistics engineers. The 
parameters involved in the analyses and requirements definition are 
shown in Figure 6. 



In the capacity of a system technical parameter, maintainability (M) 
is a characteristic of design, qualitatively and/or quantitatively 
expressed (Fig. 7), that enables timely and economical accomplishment 
of system maintenance and logistics support. This implies that some 
level of maintainability characteristics or features can be defined, 
and applied to the system development processes in the manner of a de- 
sign constraint. The level of maintainability necessary for any 
given system is directly related to defined system operational re- 
quirements and support concepts and system constraints typified by 
complexity, operational cost, and time criticality. (Time criticality 
as used here applied to systems that are launch-window critical, 
ground-turnaround-cycle critical, launch-countdown critical, etc.) 
Figure 8 illustrates the interrelationship of such program elements. 

Maintainability, as a technical parameter, is used to assess the sup- 
port impact of prospective design approaches (a tradeoff-analysis 
function) , as well as establish maintainability requirements for 
design compliance. In the role of a tradeoff factor, maintainability 
analysis is performed to establish factors such as maintenance/man- 
hour costs, support materials costs, shop and depot hardware turn- 
around costs, operational-site manning costs, personnel training costs. 
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operational downtime necessitated by maintenance requirements, and 
reaction times for emergency maintenance. Factors such as these are 
instrumental to overall program determinations of numbers of vehicles, 
types, and numbers of depot facilities/services, crossover use of 
site personnel, launch-on-time probabilities, etc. In the performance 
of such analyses, parametric-elements of maintainability are closely 
reviewed to establish effects, impact of the effects upon system 
configuration, and alternative design incorporation approaches. 

These parametric elements include repairability , replaceability , 
serviceability, accessibility , interchangeability , standardization , 
safety, fault isolation and checkout, packaging, and modularization. 


QUALITATIVE 

"The control thruster assembly 
shall be designed for integrated 
line removal/replacement actions, 
using quick-release mounting 
hardware, flange-mounted fluid 
connection points, and plug- type 
electrical connections." 


QUANTITATIVE 

"The control thruster assembly 
shall be designed such that the 
mean active corrective maintenance 
time (M ) required to effect 

line replacement shall not exceed 
1.0 hour." 


Figure 7 Maintainability Characteristic Expressions (examples) 



Figure 8 Basis for Maintainability Requirements 


30 







In the capacity of a development program function, maintainability 
works in an interfacing manner with other engineering and support 
functions (e.g., reliability, safety, quality, maintenance engin- 
eering, and logistics) to produce/update checklists, criteria, de- 
sign review reports, maintenance verification and demonstration re- 
sults, etc. As implied by available standards and handbooks, main- 
tainability functional activities occur in a waterfall fashion 
throughout the system lifespan. 

In summary, maintainability functional activities consist of the 
following steps: 

1) Define the maintenance concept. 

2) During conceptual and definition phases, define functional roles 
of logistics and maintenance programs during development and 
operational program phases. 

3) Prepare maintainability program plans . 

4) Establish maintainability design criteria consisting of quali- 
tative design features and quantitative design time goals. 

5) Perform tradeoffs, make design recommendations, and assist de- 
signers to implement maintenance requirements. 

6) Perform quantitative task predictions of design inherent 
maintainability . 

7) Provide maintainability program technical coordination. 

8) Perform maintainability integration between system element/ 
organization elements. 

Environmental Requirement - As in other functions in central systems 
engineering, definition and control of environmental requirements is 
an activity aimed at achieving consistent and complete results that 
best meet the mission requirements. The environments that have a 
significant bearing on the successful definition and design of a 
system are — 

1) natural environments that affect the system; 

2) conditions resulting from the system's interaction with the 
natural environment; 

3) environmental conditions arising from the interaction of system 
elements and system equipment. 
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Types of these environments can cover a wide spectrum depending on 
the misssion, and the survival of equipment and crews requires a 
definition of these environments. Knowledge of environments that 
exist or are propagated in each mission state; i.e., prelaunch, 
launch, ascent. Earth orbit, etc. is necessary in designing pro- 
tection or control elements. Examples of environmental conditions 
that may be encountered follow. 

Natural Environment 
Planetary 
Atmospheric 
Thermal 

Gaseous content 
Gravity 

Radiation belts 
Magnetic fields 
Space 

Radiation 

Meteoroids 

Vacuum 

Induced Environment 
Dynamic 
Thermal 
Radiation 
Man 

Vibration 

Shock 

Humidity 

Thermal 

Radiation 

Meteoroid 

Biological 

Gravity 

Several conditions establish the need for a central systems engin- 
eering environmental function. The environments involved in a sys- 
tem definition and its mission are derived by many disciplines in 
the development process . These environments become factors in the 
definition and design of system elements not directly involved in 
their determination. As with any parameters that affect many design 
activities, they must be controlled as system baseline requirements. 

Another factor in achieving uniformity in system definition concerns 
the margin of safety for environmental stresses. Most environmental 
factors are described by statistical distributions. In the defini- 
tion, design, and verification testing of the system, the model of 
the parameter is determined and then a design value is selected that 
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includes a margin or safety factor. To achieve a uniform design 
confidence, the environmental grom of systems engineering defines 
design values to be used in design >f all system elements. 

The system design problems are depicted in Figure 9. 



Figure 9 Environmental Analysis 

In this figure, the interactions that comprise the systems environ- 
mental requirements activity are shown for a single system element. 
They include — 

1) examination of the system element in each mission state; 

2) identification and quantification of applicable environments 
for each state; 
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3) examination of the system elements interaction with these environ- 
ments ; 

4) development of a design criteria to be used in definition/design 
of the system element. 

In summary, the central systems engineering environmental group is 
responsible for environmental criteria tasks as follows: 

1) Establish and maintain the program environmental design criteria, 
including thermal vibration, acoustics, shock, radiation, meteo- 
roids, planetary environments, etc. 

2) Act as the single focal point for environmental criteria control, 
specification, discussions, and presentations to customer. 

3) When the program environmental criteria includes analyses from 
other functional disciplines, thoroughly review, understand, and 
approve the input analyses. 

4) Assure that the rationale supporting each environmental defini- 
tion is correct and thoroughly documented. 

5) Verify environments with analyses and measurements as required. 

6) Establish conservative margins between actual conditions and 
design and test conditions. 

Reliability - In modern engineering technology, reliability may be 
characterized as a parameter of systems effectiveness concerning 
(1) probability of performance over a required period of time, (2) 
analysis of available strength against probable stress; (3) trade- 
off of reliability against other desired qualities, (4) cost required 
to reach a given reliability goal, (5) achievement in production of 
the reliability inherent in the design, and (6) the optimum use of 
the product in service. 

Reliability analysis has an influence on the performance of each 
of these items and applies mathematical models and statistical data 
to evaluate, compare, tradeoff, and optimize the effectiveness of 
a system. 

Reliability engineering provides resources to address the problem 
of achieving acceptable dependability of the system in the perfor- 
mance of the intended mission. Reliability deals with the charac- 
teristics failure in system elements, and therefore treats a primary 
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factor in mission success. The nature of total system reliability 
is complex, and the objective of reliability engineering is to pro- 
vide an analytical basis for assessing the system reliability and 
to establish practical approaches to achieving acceptable results. 
The analytical methods provide a means of judging the general level 
of risk and inferring a probability of success. The practical meas- 
ures selected are the means of achieving results that will be ac- 
ceptable. The balance between these two activities provides means 
for a rational and planned influence on the system to achieve de- 
sired success probability. It should be noted that the problem of 
inferring a probable outcome in a complex system where limited data 
is available does not lend itself to precise allocations and sum- 
mation of increments to yield total system assessments of reliabil- 
ity. The objective of reliability analysis is to establish that the 
margins of safety or protection are reasonable in the face of pro- 
gram and system limitations, and that a balanced solution to system 
reliability is achieved. 

Reliability and reliability analysis play an important part in the 
system engineering process and in each of the system development 
phases. The reliability analysis provides a current assessment of 
risks involved, and identifies the optimum configuration and opti- 
mum operation to achieve the greatest effectiveness for the re- 
sources expended. In summary, the reliability tasks are as follows: 

1) Establish reliability models. 

2) Establish early identification of potential problems. 

3) Establish reliability allocations. 

A) Establish reliability specifications. 

5) Identify and eliminate failure modes . 

6) Determine design and operating margins. 

7) Establish redundancy policy and criteria. 

8) Participate in Parts, Materials, and Components Selection. 

9) Prepare FMEA. 

10) Establish procurement/supplier evaluation and control. 

11) Verify launch operations - launch on-time criteria, 

- hold criteria. 
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12) Identify critical parts. 

13) Establish parts derating criteria. 

14) Identify and participate in determining checkout frequency. 

15) Identify critical storage time for applicable items (limited 
storage life) . 

16) Establish part selection criteria (high rel) (Mil Std) (comm) . 

17) Determine failure mode criteria. 

18) Reliability provides a numerical evaluation of the risks and 
the system effectiveness probabilities, 

19) Reliability identifies the optimum system and operation by 
evaluation of numerical trade studies on comparative designs. 

20) Reliability identifies and eliminates or minimizes failure 
modes by the failure mode and effects analysis. 

21) Reliability provides early identification of the problem areas. 

4 . Crew/Mission Operations Discipline 

While many disciplines can be identified as systems engineering, the 
discipline associated with operations of manned systems crosses so 
many backgrounds that it can be included in systems engineering 
only after rather careful consideration of what the discipline can 
contribute and how it should be used. For reasons which go beyond 
the mere division of labor, it may be reasonable to support the 
view that the crew and mission operations could be beneficially held 
separate. Apart from these organizational tradeoffs, the role of 
crew/mission operations can be examined under the assumption that 
the discipline exists in a systems engineering organization without 
modifying the major conclusions. 

One of the unifying elements that justifies crew and mission as a 
single discipline is the responsibility of determining how the human 
component in the system will operate and requirements and costs 
associated with this operation. The crew aspects of the disciplines 
are concerned with work loads, safety, optimum uses of man, and the 
design of the man/machine interface. The mission aspects are more 
concerned with sequences, schedules, information flow, and decisions. 
In respect to functions, crew specialists constantly review the 
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assignment of a function to the crew in terms of the impact of the 
task on the crew. The mission specialists are more inclined to 
allocate mission planning, control, and evaluation functions to 
items, and are more concerned with system output than the impact 
on the men working the system. Naturally, these distinctions are 
both artificial and incomplete since both specialties require con- 
sideration for selection and training and must constantly work back 
and forth. If the discipline were perfect, throughout the develop- 
ment of a system the characteristics of the human component could 
be precisely stated in terms of what he (the human component) re- 
quires, what he can do, how his performance can be modified, how 
he interacts with other components, how he fails, and other engin- 
eering statements concerning component characteristics. Since the 
discipline is not perfect, statements about the component are very 
inexact, and testing and design acceptance of manned systems assumes 
a major program role. 

In addition to engineering statements about the human component, the 
discipline contributes operations statements that concern system per- 
formance, workarounds, interactions with other systems, mission 
phasing, logistics, maintenance, and other domains not usually 
grouped with design. The discipline, then, is not restricted in 
interest to system design or manned flights. While it is a dis- 
cipline that is difficult to bound, it seems to be restricted to the 
development of systems that use men to meet operational objectives. 
This distinction between system design and system development as an 
objective is often not clearly appreciated during the early phases of 
the development of a program, and initial allocation of functions 
may not give adequate weight to the role of the crew or the coordin- 
ation between flight and ground operations. 

Rather than describe the discipline in terms of its organization 
relationship or in terms of the technical backgrounds of the mem- 
bers of the discipline, it may be more efficient to address the 
problem of what the discipline contributes throughout program devel- 
opment. 

CretJ/Mi^sion Operations Inputs - The use of boxes and lines to repre- 
sent program events and system development sequences is misleading 
since they suggest start and end points when in fact there is over- 
lap, rework, and successive iterations. The boxes should be used 
only as a rough map and calendar to keep track of the events that 
are associated with the inputs. (See Figure 10.) 
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Figure 10 Program Events and System Development Sequences 
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During the formulation of initial concepts, crew/mission operations 
personnel are required to provide an accurate evaluation of the 
technology base. Key decisions about initial function allocations 
to the spacecraft or the ground and to men or machines cannot be 
made without a clear understanding of the technology base. Often 
the information includes availability of flight and ground person- 
nel and the state of their training, so program dates as well as 
designs can be considered in the concept trade studies. 


During the trade studies, crew/mission operations would provide repre- 
sentative duty cycles, mission sequences, safety analyses, training 
requirements, and other factors concerning the crew or the mission 
operation that would allow a comparison of one concept with another. 


Following selection of a concept, preliminary "soft" requirements 
imposed on various systems will be tried to judge which requirements 
can be met and which should be made less severe on one system and 
more severe on another. Here again, balance between man and machine 
and between spacecraft and ground will be examined in more detail 
by a series of feasibility analyses until "hard" design requirements 
can be worked out. During the design phase, crew requirements and 
procedures will be prepared in the form of requirements documents 
and mockup, simulation, and trainer requirements describing time- 
phasing and fidelity. The degree of fidelity and the type of 
simulation or trainer selected will have great cost and time impacts. 
These requirements will be traded using crew confidence, procedures 
confidence, and mockup cost as the principal criteria. 


During the design phase, use of mockups and preparation of analyses 
of crew tasks will produce changes to the design and the beginnings 
of operational procedures development. Using flight-similar arti- 
cles (often referred to as trainers), operational procedures will be 
developed and the selected flight crew will begin practicing antic- 
ipated tasks. Designation of the ground team will begin and communi- 
cations and responsibilities of the teams will be clarified. Design 
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objectives cannot be economically or safely performed with the de- 
signed hardware. These modifications can be used to provide valuable 
design feedback in preparation for the next mission design. 


During the actual operation of the mission, the system engineering 
design team will be required to provide analyses of unusual or off- 
nominal performance of system elements and develop alternative 
methods of operation or inflight modification in support of opera- 
tional personnel. 
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In summary , systems engineering functions associated with the crew/ 

mission operations discipline are as follows: 

1) Coordinate with all disciplines in optimization of mission ob- 
jectives and requirements. 

2) Generate data requirements necessary for mission operation and 
evaluation. 

3) Generate mission documents such as various program support re- 
quests that are required by different technical disciplines. 

4) Conduct mission analysis to determine: integrated timelining 
of events (i.e., crew, experiment, spacecraft, and system se- 
quences); contingency planning; compatibility of systems versus 
mission requirements; identification of constraints associated 
with mission requirements ; compliance with flight/mission pro- 
gram objectives; experiment and flight vehicle system data re- 
turn requirements; airborne/ground net capability and compati- 
bility required to satisfy data management requirements. These 
activities are performed in conjunction with trajectory anal- 
ysis and navigation activities performed by other personnel. 

5) Evaluate the technology base and provide initial allocation of 
functions to spacecraft versus ground and to manual versus 
mechanization. 

6) Determine launch mission rules and launch constraints as imposed 
by flight operations. 

7) Integrated flight mission rules. 

8) Perform flight operations implementation of payload/experiment 
systems and consumables monitoring requirements. 

9) Assist in training of flight controller and support personnel. 

10) Determine operations support requirements. 

11) Perform definition and implementation of simulations required 
for training and software development. 

12) Perform ground network support analysis and requirements defini- 
tion. 

13) Determine technical operations support and/or flight controller 
responsibility during mission. 
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14) Determine flight controller and operations support procedures . 

15) Determine flight operations and flight simulation ground equip- 
ment configuration requirements. 

16) Integrate operations support software requirements. 

17) Coordinate operations requirements generated by other engineering 
areas . 

18) Determine antenna coverage requirements during abort and alter- 
native missions. 

19) Coordinate engineering discipline support required during opera- 
tion of the mission. 

20) Provide data concerning crew and mission operations for pre- 
liminary trade studies. 

21) Perform crew operations activities as follows: 

a) Determine human factors design criteria, standards, and re- 
quirements . 

b) Perform crew task analyses , time lines and workload determin- 
ation. 

c) Perform mission feasibility analyses and man/machine function 
allocations . 

d) Determine life support requirements and crew schedule con- 
straints. 

e) Provide inputs to manned simulation plans, associated data 
analysis, and recommendations. 

f) Provide crew-oriented inputs to raockup and trainer requirements 

g) Determine specific man/machine interfaces and verify system 
performance by test. 

h) Develop contingency procedures for crew. 

i) Assist in EVA equipment requirements and procedures development 


41 


j) Determine crew station layout, control and display readability/ 
operability requirements and analyses; link analyses; anthro- 
pometric analyses; fault isolation procedures and critical skills 
analyses. 

k) Provide design data during training, procedures development, 
operational and postoperational phases. 

l) Assist in preparation of crew operating procedures and hand 
books. 

m) Perforin crew procedures integration and compatibility analysis. 

n) Assist flight crews in system design reviews. 

o) Review all GSE design for compliance with program human engin- 
eering requirements . 

p) Determine crew recreation time requirements. 

5. System Verification 

Systems engineering verification provides skills and methods for 
planning and implementing an integrated design and premission verifi- 
cation program as a part of the definition/design of a system. As 
in other central systems engineering functions, design and premis- 
sion verification requirements and approaches have an impact on all 
system elements and are a direct factor in mission success confi- 
dence. The objectives of this function are to establish consistent 
test checkout and analytical approaches for all elements of the 
system, and to realize the maximum confidence in mission success 
with minimum cost to the program. 

System design and premission verification starts in the concept 
phase where general test and checkout philosophies are examined 
in conjunction with system operations analyses. In this phase of 
system development, concepts are identified and examined as part of 
operational availability feasibility analysis where reaction time or 
frequency of checkout are factors. 

The main functional activities of system verification occur in the 
definition/design phase. In this phase, systems verification 
establishes the verification concepts and requirements baseline that 
governs the definition and design of mission and support system 
elements. The initial activity is the development of an integrated 
system verification plan. This plan is aimed at establishing consist- 
ent approach to testing and checkout verification in all design. 
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development and premission states (development testing, qualifi- 
cation, production, acceptance, storage, system assembly, integrated 
system checkout, launch countdown) to assure that at each level of 
complexity, total system, system element, subsystem, component and 
part, that the verification approaches are consistent, complete, 
and provide a desired degree of confidence. Interaction with other 
design and systems engineering disciplines occurs in the systems 
analysis to find a compatible initial requirement that can be used 
to drive the definition process. Once these requirements have been 
set, they become part of the systems criteria and are directed to 
all disciplines. Subsequently, systems verification expands on 
these criteria as system element designs evolve and participate in 
trade studies where verification requirements are factors in the 
selection process. In the final stage of each phase, systems veri- 
fication evaluates the system definition and design to determine 
that verification requirements have been completed and that the 
total system verification approach is complete. In summary, the 
following specific activities constitute the systems engineering 
verification functions. 


Systems Test Integration and Requirements 


1) Develop integrated test plans that define total program test 
requirements, including development, qualification acceptance, 
and operational testing. 

2) Develop operational functional flows and timelines of program 
test and checkout requirements. 


3) Define test support requirements necessary to accomplish test 
requirements at offsite locations. 

4) Prepare and maintain the test section of system specifications 
and interface specifications. 

5) Establish and implement test program trend data analysis. 

6) Integrate detailed test requirements and success criteria for 
integrated system testing. 

7) Define system retest requirements for component replacement 
policy. 


8) Develop backout requirements for test phases where backout 
is critical to personnel or equipment. 
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9) Coordinate and document detailed engineering test requirements 
for special tests. 

10) Review and approve test sequence plans and system level test 
procedures prepared in compliance with test requirements. 

11) Monitor test program implementation to assure accomplishment 
in accordance with the intent of technical requirements . 

12) Accomplish test analysis and prepare test reports on system 
level development and qualification tests. 

Environmental Test Requirements - Responsible for environmental and 

qualification test requirements as follows: 

1) Establish environmental test requirements for components, sub- 
system and system testing as required. 

2) Coordinate and establish component test plans defining program 
technical requirements for component development, qualification 
and acceptance testing. 

3) Review and approve environmental test fixtures and procedures 
including those required for qualification and environmental 
acceptance test (EAT) . 

4) Monitor environmental development, qualification, and EAT testing , 

5) Review and approve qualification and system environmental test 
reports, and negotiate results with customer. 

Systems Test Analysis and Control - Responsible for systems test 

implementation as follows: 

1) Perform integrated mission/support equipment system analysis 
to implement system test sequencing and control for combined/ 
integrated system test. 

2) Define and control detailed step-by-step logic command /stimulus 
and/or expected response success criteria for item 1. 

3) Review and approve all systems test procedures prepared to 
implement the tests of item 1. 

4) Prepare and maintain documentation to identify usage and alloca- 
tion of mission-peculiar hardware and software affecting accept- 
ance test and operational usage of each article. 
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5) Provide engineering support required in above areas to implement 
rapid mission change, turnaround, and contingency operations. 

6) Assure that instrumentation/data is provided to accomplish 
adequate system test performance evaluation and fault isolation. 

7) Accomplish trend data analysis on system tests as required by 
the program. 

6. System Design and Integration 

System design provides and applies processes required to establish 
an optimized system technical approach (definition) from given 
requirements, develops compatible design requirements, and monitors 
the evolution of the design to assure that system design requirements 
are met. 

The overall goal of systems design is to optimize the technical path 
from given system requirements through the verification phase of 
the program. 

System Defirvltian - The process of developing a system level design 
or design concept to meet the technical requirements is the system 
definition. This is accomplished through application and coordina- 
tion of specialized engineering disciplines, past experience, and 
knowledge relative to the state-of-the-art, and culminates in the 
establishment of the gross configuration of the system elements. 
Although only basic approaches are defined at this point, consid- 
erable sublevel system design insight is required to reduce the 
risks of downstream iterations subsequently impacting the top level 
approach. This risk can be reduced by involving project management, 
key personnel from other systems engineering disciplines, and key 
design specialist personnel, as required, and by developing an accur- 
ate and thorough understanding of the given system requirements. 

Systems engineering tools applicable to orderly establishment of a 
system definition include functional analysis, design synthesis, 
trade studies, and system block diagrams. For the resolution of 
critical, top level concept decisions, it may be necessary to employ 
tools of a more detailed nature; e.g., mathematical models or tra- 
jectory programs. 

The approach resulting from this program phase will encompass both 
performance and top level design requirements and must be documented 
in a system block diagram, functional analysis results, or other 
formalized means, and preserved along with applicable trade studies 
to form a basis for the systems design criteria. 
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System Requirements Definition - Systems has the lead role in estab- 
lishing, coordinating and documenting the system and subsystem de- 
sign requirements, which will constrain and control the technical 
effort during the design definition phase. 

This is accomplished through use of controlling systems and sub- 
systems design criteria and interface control requirements. The 
process of establishing design criteria consists of technically 
interpreting the systems definition, defined above, in terms of, 
first, a systems design criteria, and subsequently, criteria for 
each significant subsystem or design discipline appropriate to the 
program. The process is a progressive analysis of functional re- 
quirements, leading to definition of a system of hardware, software, 
and technical tasks to fulfill the requirements, and generating the 
detail requirements for these elements. This process is continued 
to a level of detail beyond which technical assignments can be made 
to specialty technical groups with a low risk of experiencing system 
integration or compatibility problems. 

The tools employed to develop these criteria include sizing studies, 
trajectory analysis, loads analyses, stability analyses, accuracy 
and tolerance analyses, etc. Systems engineering has primary respon- 
sibility for coordinating, generating portions of, and assuring com- 
patibility of these criteria. All other systems engineering disci- 
plines are intimately involved in this task, and the technical de- 
sign areas have significant contributions, particularly in the gen- 
eration of subsystem criteria. 

Products of the system design requirements function follow. 

System Schematic Diagrams - First level schematics depict system 
segments and end items and the interface relationships among them. 
Second level schematics are expansions of the first level schematics 
and are prepared for each subsystem or end item to depict the sub- 
system and major component interrelationships. These schematics may 
be incorporated into the system and subsystem design criteria, re- 
spectively. 

Functional Time Line - This depicts in sequential format the time/ 
event relationship constraints for the system mission or operation. 
This may also be incorporated into the design criteria. 
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Design Criteria - The system criteria establishes requirements and 
constraints that will be imposed upon the design of the total sys- 
tem. This criteria contains the performance, operation, and design 
implementation requirements for the major system elements. This 
criteria expands the customer requirements contained in the SOW and 
specifications, and is based on System Definition, Section b, 5 of 
this chapter. 

Subsystem/element/end item criteria contain the performance, opera- 
tion, and design implementation requirements for the system segments, 
subsystems, and end items of hardware and software. These criteria 
expand the requirements contained in the systems criteria so that 
a competent designer or design organization can design the element, 
subsystem, or end item without further definition of requirements. 

Interface Requirements - Interface requirements define design and 
functional interrelationships among the major system segments, or 
between segments that are independently developed; e.g., subcon- 
tracted end item, or associate contractor program. These require- 
ments may be documented in separate interface control documents, or 
may be incorporated into the system and subsystem design criteria. 

Requirements that are contained in the various criteria documents 
listed above must be based upon sound rationale and should be 
traceable to their origin. The requirements in these documents 
should reflect results of functional analyses, allocation of system 
requirements , trade studies, sizing analyses, customer direction, 
etc. Systems design personnel are responsible for documentation 
and dissemination of system design requirements, and for maintaining • 
requirements until (typically) the critical design review point in 
the program. 

System Requirement Integration - Systems design assures that system 
design requirements (described above in System Requirements Defini- 
tion are, in fact, complied with as the design development phase of 
the program progresses. 

The system design goal of this task is to assure that the design 
develops as a system rather than as a collection of unrelated items. 
This is accomplished by a continuous, systematic surveillance of de- 
sign development outputs, including end item specifications, inter- 
face specifications, analytical studies, detail design drawings, 
functional schematics, test data and reports, and acceptance test 
specifications and data. These outputs are reviewed for compatibil- 
ity with the intent of requirements documentation. Systems design is 
responsible for conducting compatibility reviews, identifying and 
tracking the problems, and coordination of systems-related corrective 
action. 
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Systems design will direct particular attention to surveillance of 
interfaces between adjacent designs created in separate areas of 
responsibilities to assure that the designs are mutually compatible. 

Although requirements integration is a continuing process throughout 
the design development phase, program reviews (described in the 
following paragraphs) offer discrete checkpoints in the program where 
formal integration assessments can be made. 

Design Reviews - Design reviews are formal, technical reviews of a 
system or system segments to establish adequacy and system compati- 
bility of design. The purposes of the reviews are to assure program 
management, central engineering, and/or customer program monitors 
that the studies performed and the products designed are of the 
highest possible quality consistent with time and budget limitations, 
and to assure that these products satisfy system design requirements. 

Design reviews may be scheduled at various stages in a program, de- 
pending on particular program requirements , but generally reviews 
are held to confirm establishment of design concept, after prelim- 
inary design is complete, and prior to release of final engineering. 

Systems design personnel, in conjunction with project management, 
schedule convene, and conduct the design reviews. Responsibility 
for specialized disciplines presented at design reviews is delegated 
to key personnel from other systems engineering organizations (e.g., 
Reliability) and from the specialist design groups (e.g.. Structures). 
It is also the responsibility of systems design personnel to assure 
the presence of appropriate personnel from without the immediate 
project area so that a broader base of technical competence and the 
experience gained on other programs may be applied. 

The presentation approach used in design review is aimed at verifying 
traceability of evolving design factors and compatibility with the 
documented design requirements. Methods employed may be a complete, 
systematic, checklist presentation of design requirements versus de- 
sign status; or a more efficient presentation "by exception" wherein 
only those areas are presented that are known or suspected problems. 

In summary, within this discipline, system criteria, technical speci- 
fications, and other system engineering documentation are developed 
and maintained. Overall system design is established and all ele- 
ments are integrated into the functional system. The major specific 
tasks to be performed follow. 
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1) Establish system requirements and define basic system config- 
urations . 

2) Perform systematic system and subsystem design analyses from 
compatibility and functional aspects. 

3) Conduct system design reviews. 

4) Perform technical renews and assessment of all design change 
activity. 

5) Participate in or lead trade studies for system design optimi- 
zation. 

6) System Element Integration — 

a) Perform overall integration between major system elements. 

b) Define interface requirements and constraints between major 
system elements. 

c) Coordinate interface definition activity within engineering 
functional activities. 

d) Serve as single point engineering contact for systems 
integration among organizational elements. 

e) Conduct design and integrity reviews and compatibility 
analysis. 

7) Electromagnetic Compatibility — 

a) Generate and maintain EMC control and test plans. 

b) Participate in or chair EMC technical working groups. 

c) Review all design engineering for compliance with require- 
ments . 

d) Monitor subsystem EMC tests and conduct system EMC demonstra- 
tion tests. 

e) Establish design requirements for EMC test tooling. 
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8) Design Review Management — 

a) Establish need for reviews, types of reviews, review 
schedules, and major participants, through coordination 
with project. 

b) Establish review teams. 

c) Prepare design review directives. 

d) Participate in management panel as secretary, recording 
action items, and assuring their inclusion on proper open 
items list. 

e) Maintain records of reviews, track action item closures, 
and method and suitability of disposition. 

7. Integrated Logistics Support 

The logistics support functional activities are included under cen- 
tral systems even though it is generally a separate organization. 

The reason for this is that the integrated logistics support ele- 
ments make up a complete system in the sense that they consist of 
equipments, facilities, personnel, and procedures that function to- 
gether to determine mission related requirements. These require- 
ments are correlated with the mission system and the accomplishment 
of the overall mission objectives. This relationship is illustrated 
in Figure 11. 



Figure 11 Total System Configuration 
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The systems engineering functional activities relate directly to the 
effectiveness of the system in performing the mission and in mini- 
mizing the cost, and in cost effectiveness* The logistics support 
is one of the primary factors in achieving a specified level of 
availability. This parameter is a measure of assurance that the 
system will be ready to perform the mission when called on to do so. 

To provide effective logistics support for a system, with maximum 
cost effectiveness, an optimum balance must be maintained between 
the quantities and types of spares selected, and the maintenance 
requirements, reliability, and maintainability implications. Pro- 
vision of the least costly set of spares may create a repair/re- 
placement situation that is very costly, or conversely, the most 
economical maintenance situation in terms of equipment and person- 
nel may require a costly set of spares to complement it. Added to 
the complexities of achieving this economical balance of spares and 
maintenance requirements are such specific requirements as mainte- 
nance reaction times, maximum allowable downtime, and maintenance of 
acceptable levels of system safety. 

To achieve optimum system effectiveness, analyses to define logistics 
requirements must begin early in the system concept and definition 
phase and continue as an iterative process through completion of 
detail design. The logistics analyses must also be integrated with 
other systems analysis /systems engineering activities because of 
interactions with other elements. The many conditions imposed 
create a requirement for objective, systematic methods for evaluating 
alternatives; i.e., tradeoff techniques to assist the decision making 
processes. The general approach to this problem is to express all 
maintenance effort (manpower, test equipment, technical data, and 
maintenance support facilities) using personnel of average skill under 
operational environment conditions in which scheduled and unscheduled 
maintenance will be performed. Note that this characteristic should 
be distinguished from "repairability" with which it is often identi- 
fied as synonymous, and which excludes the additional coverage of 
ease of preventive maintenance and servicing. 

Maintainability influences the downtime, once a failure has occurred. 
Downtime can be decreased by a system that can be readily repaired 
or serviced. 

Logistics depend upon those characteristics of design and install- 
ation that determine the probability that the system will conform 
to specified operational performance requirements, or state or 
readiness, when supported within the resources of the available per- 
sonnel subsystem and logistics support and maintenance. It is an 
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element of both logistical systems effectiveness and operational 
readiness and, thereby, of operational systems effectiveness. 
Logistics supportability can be evaluated as the economy in time, 
men, support materiel, and facilities, and their cost. 

Logistics influence availability through waiting time for repair 
or service which, in turn, may be functions of spares, distance, 
speed, and design delays. It also includes waiting for parts, facil- 
ities, personnel, etc to become available. 

At the system level, modeling techniques are developed for combining 
maintainability, safety, reliability, etc parameters to establish 
values of these parameters that meet the availability requirement 
for the system. Probability of launch-on- time analysis models, for 
example, provide the means for examining the problem in terms of 
mean times between failure (MTBF) and mean time to repair (MTTR) , 
and the launch operation time line. Logistics together with system 
effectiveness develop the means for translating MTBFs, MTTRs , fail- 
ures critical to safety, FMECAA, into meaningful design parameters. 

This translation takes the .form of reliability, maintainability, 
and logistics criteria and policies that govern the definition/de- 
sign of the system. 

The logistics criteria ultimately selected for the definition/design 
of the system must meet the following requirements. They must be — 

1) quantitative; 

2) sufficiently meaningful to the system designer and system 
analyst to permit their use as design and evaluation criteria 
for a given system; 

3) sufficiently meaningful to the user and mission analyst to 
permit their value to be specified and interpreted in terms of 
the mission. 

The systems engineering activities involved in the development of 
the logistics support system follow. 

1) Develop logistics baselines that delineate all the tests, check- 
out, and operational functions for which logistics support must 
be provided. 



2) Determine a maintenance policy for the total system; i.e., where 
maintenance will occur (depot or field), level of maintenance 
(black box or component), testing requirements after repair, 
preventative maintenance versus corrective maintenance, etc. 

3) Determine spares policy for all operational phases of the mission 
system; i.e., level of spares, location of spares, spares deter- 
mination, spares provisioning, etc. 

4) Determine equipment requirements for maintenance activities; 
i.e., tools, tool kits, test equipment, ground support equip- 
ment, etc. 

5) Determine facilities requirements. 

6) Determine personnel and skill requirements. 

7) Determine procedure requirements. 

8) Determine base support requirements for maintenance activities. 

9) Determine training requirements, training equipment requirements. 

10) Conduct training courses. 

11) Plan transportation activities. 

8. Summary 


The central systems engineering discipline provides skills and pro- 
cedures to address the system development problem in terms of the 
factors that make up the design verification and use of the system. 
These factors cover the specialist areas of design and integration, 
system performance, system effectiveness verification and crew/ 
mission operations. These factors all have the characteristic of 
broadly affecting all elements of the system, and thus affect "what 
technical disciplines do" in the definition of concepts and design 
requirements for system elements. This relationship results in the 
matrix organization structure shown. 

The crossover points identify interrelationships in which technical 
disciplines participate in the definition of the system. The nature 
of the relationship and the functions performed by the technical 
disciplines in the total system definition are discussed in the next 
section. 
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B. 


SYSTEMS ENGINEERING FUNCTIONS OF TECHNICAL DISCIPLINES 


Design disciplines are an integral part of systems engineering 
and perform functional activities that have a direct bearing on 
the consistency and completeness of the total system. The system 
functional activities of design disciplines include management 
activities performed at the organization level and thos performed 
by the design discipline groups involved in system development. 

In the following section, management activities of design disci- 
plines and the subsequent system functional activities of the 
technical discipline groups will be covered. 

a. System Functional Activities of Technical Discipline Organizations 

The technical disciplines engaged in a system development are 
organized in many ways, depending on management judgment. What- 
ever the structure, specialists are grouped together from both a 
project and a disciplinary point of view. Figure 12 illustrates 
this concept. This section is concerned with systems engineering 
activities of these organizations, the objectives , and their re- 
lationship to the central systems discipline. 

These systems engineering activities may or may not be identified 
as organization elements but the roles and responsibilities never- 
theless must be identified and recognized as part of each design 
discipline. Imp lemen t at i on of systems engineering as a workable 
factor in the engineering organization, the relationship between 
the systems engineering discipline and those of the technical 
disciplines must be specific and well defined. 

The functional activities of the engineering organizations (elec- 
trical/ electronics, structure /mechanical, flight mechanics /aero- 
ballistics, etc), are uniformly the same and represent the means 
for implementing systems engineering activities. These activities 
fall into the categories of requirements synthesis and design, 
and evaluation. 

1. Requirements Definition and Control 

In the definition and design phases, system requirements are com- 
piled and issued as direction at the beginning of each phase. 
During the phase activity these baseline requirements are main- 
tained (modified and expanded) , and at the end of the phase are 
source data for specifications that govern the next phase activ- 
ity. The systems function in each design organization performs 
the following activities for the specialist groups represented. 
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1) Participate in the initial requirements analysis for expansion 
of requirements into a baseline; for example: 

Flight mechanics/aeroballistics — 

Identify and describe reference trajectory. 

Define reference atmospheric model. 

Structures/Mechanical — 

Identify approved materials list (flammability/outgassing) . 

Define system outboard/inboard system profile to be 
studied and/or defined. 

Identify dynamics characteristics. 

Electrical/Electronics — 

Identify basic electrical power type and quality. 

Identify initial allocations to all users. 

2) Provide the means for implementing system requirements in 
each design specialty area and assure that each design spe- 
cialty area identifies and employs these requirements in the 
definition/design process. 

3) Maintain cognizance of all deviations from system require- 
ments and coordinate these with central systems and obtain 
disposition (approval/disapproval) . 

4) Maintain visibility to the expansion of requirements in each 
specialty area (guidance, structure, electrical power, etc) 
by maintaining functional models, block diagrams, schematics, 
and other descriptive data. 

5) During definition/design, compile and integrate requirements 
that must be implemented by other organizations, and coordi- 
nate with the receiving organization; for example, all elec- 
trical/electronic systems facility requirements would be com- 
piled and described and transmitted to the organization re- 
sponsible for further compilation and integration prior to 
transmission to the facility design agency. This activity 
would be performed using the documentation and procedures 
specified by central systems. 
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6) Assure that the methods and documentation for identification, 
functional definition and solution of interfaces is employed. 

7) Participate in interface panels and assure that proper special- 
ists are involved. 

8) Maintain cognizance over scheduled commitments and identify 
technical requirements inputs required as well as outputs to 
other organizational elements. 

9) At the end of each phase, assure that the output specifica- 
tion approaches defined by central systems are implemented. 

10) Compile specification requirements and provide them to central 
systems for integration into specifications that will govern 
the next phase activity. 

11) Provide task data definition for inclusion in the SOW, WBS, 
and data requirements lists for RFP and contracts for the 
next program phase. 

12) Identify general requirements for methods /techniques and de- 
sign, and construction standards that govern the next phase 
activities. 


Synthesis and Decisions 


Within each design organization the definition/design activities 
subsequent to definition of requirements is the selection of a 
design solution that best meets the composite requirements. In 
this activity, the systems engineering element of each design 
organization provides the skills and resources to assure that the 
selection of solutions is based on merit to the system, and that 
the solutions (configuration, preliminary, or detail design) are 
integrated into the system. The specific functional activities 
follow. 


1) Assure that the methodology for conduct of trade studies is 
implemented by design specialist. 

2) Provide an identification of all trade studies that have been 
identified as potentially having impact on the total system. 

3) For the trade studies in item 2) , review and evaluate the 
trade studies for compliance with requirement for content and 
selection criteria. 
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4) Act as a focal point contact with central systems and the 
project for trade studies involving other organizations and 
design disciplines. 

5) Maintain a list of problems, open items, discrepancies, and 
follow up on their resolution. 

6) Provide a single point contact for interface with central sys- 
tems specialists (reliability, safety, verification, etc) for 
the implementation of these requirements into the synthesis 
solutions . 

7) Maintain control over simulations and performance models that 
form the basis for sizing and allocation of system performance ; 
i.e. , trajectory simulation, structural model, analysis model, 
guidance error analysis. 

8) Maintain cognizance of configuration and design solution de- 
scription and backup data (schematics , drawings , analyses , 
studies , etc) . 

Evaluation 

The evaluation of results in the definition/design phase is made 
up of periodic indepth assessments of the development results. 

These assessments are made at all levels of system complexity and 
program organization to determine that the planned cost, schedule, 
and technical results are being achieved. The types of reviews 
in a program are program status, program baseline, system design, 
detail design, change control board meetings, and intercontractor 
or agency reviews. 

In each of these activities, the systems engineering group of the 
technical organizations involved will — 

1) Provide representation for the technical speciality groups in- 
volved in program and system reviews. 

2) Present technical status and report on problems. 

3) Plan and conduct design reviews of each subsystem and follow 
up on problems and discrepancies. 

4) Review and assess program and system changes to concepts , re- 
quirements, and design solutions for impact on subsystems. 
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In summary, the systems engineering element of each design engi- 
neering organization performs functions that implement the central 
systems requirements and provide the focal point for technical 
specialties in interaction that takes place between central sys- 
tems and project functions. 

b. Systems Engineering Functions of Technical Discipline Groups 

The engineering and scientific disciplines provide skilled re- 
sources that transform mission requirements into solutions de- 
scribed by performance and design requirements and system element 
concepts. These disciplines are identified and assembled by 
project management in each program phase and make up the techni- 
cal development team. These disciplines provide the creative and 
innovative skills to conceive and define equipments facilities, 
personnel, and procedures that work together and collectively 
constitute the total system. 

The functional activities of these technical disciplines can be 
of two types: those that have a significant bearing on the total 

system, and those that have impact on the characteristics and per- 
formance of a subsystem resulting in no significant system effect. 

The systems engineering functional activities of technical disci- 
plines are those that directly involve selection of a solution 
that best meets the performance requirements of the mission and 
system design requirements. 

The mission performance requirements are those that can be traced 
directly to mission requirements of each mission state; i.e. , de- 
livering the payload, performing the object mission, and return- 
ing the payload and/or data. To illustrate this type of mission 
requirement , the mission analysis of a payload delivery system 
identifies a guidance and navigation accuracy requirement. Guid- 
ance and navigation design specialists would conceive flight and 
ground guidance schemes to achieve this mission capability. In 
this example, the guidance discipline would thus directly impact 
a primary mission requirement. 

The system design requirements are those that central systems 
engineering and other technical disciplines establish as a part 
of the system definition/design process that must be implemented 
by a technical discipline for the system to be complete and inte- 
grated. To illustrate this, the best system solution to the guid- 
ance and navigation problem, the guidance discipline is faced with 
the following requirements : 
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mission accuracy; 

reliability allocation; 

weight allocation; 

mission duration ; 

safety requirements; 

maintainability requirements ; 

crew control requirements; 

attitude control requirements ; 

electrical power allocation; 

flight controls performance characteristics; 

propulsion characteristics; 

mission sequencing requirements. 

These and other interrelationships define the type of problem 
faced by each design discipline in conceiving, defining, and de- 
scribing a design solution. 

The interrelationship with other disciplines and within the cen- 
tral systems engineering discipline is illustrated in Figure 13. 
This figure shows that each discipline is a focal point for a 
specific part of the system and has an iterative relationship 
with these disciplines. 
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The synthesis of solutions by technical disciplines of system 
elements is an integrated team activity in most cases. The per- 
formance and design characteristics of system elements are highly 
correlated and it is not generally possible for a solution to be 
developed independently of other disciplinary activities. The 
definition of guidance equipment by a guidance discipline is an 
example of this. The system performance sizing is a highly cor- 
related interaction of guidance, propulsion, structure, flight 
controls and flight mechanics disciplines. These disciplines 
come together to describe the mission problem in terms of inte- 
grated analyses and simulation studies with the objective of find- 
ing solutions that are mutually compatible and meet the overall 
system performance. 

Another type of systems engineering functional activity involves 
setting requirements or defining solutions that have a broad ef- 
fect on other elements of the system. Each discipline, devoted 
to definition of some portion of the system makes decisions that 
must be considered in other system element designs. For example, 
the following are established by design disciplines that have a 
broad system effect: 

1) Approved Material - Materials specialists determine the ma- 
terials properties that are necessary from the standpoint of 
mission compatibility. The result is an approved list of ma- 
terials that must be used in all designs. The materials and 
processes characteristic may be, as in the case of a manned 
system, flammability and outgassing. 

2) Electrical Fewer - The electrical engineering discipline 
determines the type of electrical power to be generated and 
distributed to the system equipments. This definition of 
voltage, frequency, and allocated capacity and grounding 
philosophy become system requirements that affect the defini- 
tion and design of other system elements and subsystems. 

3) Communications Capacity - In sizing the communication system, 
communication specialists determine the capacity (number of 
channels, number of functions, etc), and allocate these to 
users. The allocation of capacity together with sensitivity 
and accuracy of this system become constraints that affect 
the subsequent design of other system equipments. 

This type of "system" requirements become, part of systems require- 
ment baseline developed and issued sis a directive by central sys- 
tems engineering for each system development phase. 
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The design disciplines also perform systems engineering activities 
as a part of the management and execution of the development in each 
phase. As described in Section V,A,a, central systems engineer- 
ing functional activities , a key factor in achieving total system 
objectives is a baseline requirements management approach. In this 
approach integrated and compatible requirements initiate each 
phase and are maintained and updated during each phase by central 
systems engineering. Progressively, baseline requirements are up- 
dated by formal program and design reviews. 

The design disciplines are involved in this activity in terms of — 

1) contributing to the initial requirements; 

2) participating in the maintenance (revision and update) of sys- 
tem requirements ; 

3) providing output results of phase activity (configuration, 
description, and performance and design requirements) ; 

4) supporting and participating in program and design reviews; 

5) participating in resolution of interfaces between system ele- 
ments and subsystem. 

Another type of technical discipline systems engineering func- 
tional activity, an integration activity, results from the organi- 
zational structure of the program. Where the system elements are 
developed by a combination of contractors and agencies, the defini- 
tion of technical requirements established the need for a special 
integration activity. An example of this is found in thermal 
analysis. The thermal control requirement for a spacecraft sys- 
tem is a function of an integrated thermal analysis of the space- 
craft in each mission state. This spacecraft may be composed of 
a number of modules and a variety of payload and engineering 
equipments which involve several contractors and agencies. The 
analysis that sizes and defines requirements for each module must 
be an integrated model of the total spacecraft definition would 
therefore develop, in conjunction with the module contractors and 
agencies, an integrated thermal analysis model which would be used 
to size the thermal control system. The technical discipline 
charged with thermal analysis in the spacecraft program organiza- 
tion would perform this function. This type of design discipline 
integration activity has a significant impact on the consistency 
and completeness of the total system. Such activities are a part 
of the interface definition and form the basis for making inter- 
face decisions and verifying the validity of interface solutions. 
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In summary, the technical disciplines in the system program organi- 
zation perform systems engineering functions to integrate the 
activities within the discipline to assure that the requirements 
definition performed by elements of the system are consistent and 
constitute a total system solution. In general, these functional 
activities follow. 

1) Integrate requirements. 

2) Identify and select concept candidate. 

3) Establish and allocate subsystem requirements. 

4) Perform integration analyses for requirements definition and 
system concept definition. 

5) Perform interface definition and coordination. 

In general the systems engineering functional activities of the 
technical disciplines are described as follows: 

1) Perform an analysis of mission, systems and subsystem require- 
ments and identify the concepts that are candidate solutions. 

2) Implement the system trade study requirements provided by 
central systems in selecting feasible approaches. 

3) Develop models, simulations for allocating, sizing, and 
evaluating performance and design requirements and solutions 
for subsystems of system elements. 

4) Generate and provide to systems engineering performance and 
design requirements and constraints that broadly affect the 
total system. 

5) Collect requirements that affect other system elements and 
provide them to the organizational elements that are charged 
with its design. 

6) Assure that interfaces between subsystems are completely de- 
fined in terms of requirements and solutions. 

7) Participate in interface working groups for the resolution of 
interface definition and solution. 
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8) Plan, organize, conduct, and follow up on design reviews of 
subsystems periodically in the development process to assure 
system requirements are being adequately implemented. 

9) Support system and program reviews with data and representa- 
tives to assist in the examination of the system elements for 
system compatibility. 

10) Develop and maintain descriptive data showing subsystem 
functional, performance, and design characteristics, and 
serve as a single point contact with project and central 
systems engineering. 

11) Compile and provide to central systems engineering output 
results of each program phase for inclusion in specifications 
that will govern the next phase activity. 

12) Provide task definitions , data requirements for inclusion in 
WBS , Statements of Work and data requirements lists. 

13) Provide applicable design and construction and methodology 
standards that should govern the next program phase. 

The specific systems functional activities of individual design 
disciplines are in many cases unique to the system element or 
subsystem being defined. Since there is a wide variety of design 
disciplines, the system engineering activities of a representa- 
tive set of disciplines are discussed in the following paragraphs. 

Figure 14 represents the fundamental design process showing the 
functions of central systems engineering and the technical disci- 
plines. The upper part of the matrix shows the requirements 
definition and synthesis involved in a typical launch vehicle 
system development, while the lower part of the matrix shows the 
evaluation process of the system element concepts as performed by 
central systems engineering. 

In Figure 14 typical system elements are shown on the left side 
of the matrix; at the top typical technical disciplines that are 
involved in the design of the system elements, and the system 
requirements that are imposed on the elements are shown. Shown 
in the vertical axis of the matrix is the source of requirements 
for the design of the system elements (the upper part of the 
matrix) and the resultant design concept (the lower part of the 
matrix) . The source of requirements is indicated by a solid dot 
(•) under each technical discipline or system requirement that 
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impacts the element design concept. The resultant design concept 
is indicated by Q. For example, the propulsion technical disci- 
pline has prime responsibility for designing the propulsion sub- 
system; the design of the propulsion subsystem, however, impacts 
and imposes requirements upon the design of the flight vehicle, 
the flight control subsystem, and the structures subsystem. It 
is possible that each of the technical disciplines can impact and 
impose requirements upon a given system element. It is for this 
reason that all the requirements from each of the technical disci- 
plines, as well as the systems requirements, must be considered 
in a system element design. 

The horizontal axis of the upper part of the matrix shows the 
possible requirements that must be considered in the system ele- 
ment design, and the technical discipline that has the responsi- 
bility for synthesizing the requirements for the system element 
design. For example, the flight control subsystem must consider 
requirements from the technical disciplines of flight mechanics/ 
aeroballistics, propulsion, flight control, guidance, structures, 
and GSE as well as the system requirements of performance, sys- 
tem effectiveness, verification, design and integration, and 
logistics. The synthesis of all these requirements is a systems 
engineering activity performed by the technical discipline having 
responsibility; in the case of flight controls, the flight con- 
trols technical discipline. This responsibility is noted on the 
matrix by the symbol @ . These requirements must be approved 
by central systems engineering prior to concept definition/design. 

In the lower part of the matrix, the system element designs are 
shown on the left side. The requirement against which the system 
element design must be evaluated is indicated by the symbol . 

For example, the communications subsystem must be evaluated in 
terms of its performance capability, systems effectiveness, veri- 
fication requirements , design and integration requirements , mis- 
sion and crew operations requirements, and logistics requirements. 

The above described process is highly iterative and must be con- 
tinually updated as design progresses. 

2. Examples of Systems Engineering Functions 

Flight Mect^ ( Figure 14 Item 1) - The develop- 

ment of an aerospace system in general involves payload and deliv- 
ery system elements and the definition and design of each is separ- 
ate but highly correlated. Figure 15 shows, in block diagram 
form, the life cycle sequence for a launch vehicle definition and 
design. The payload performance and design requirements lead the 
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vehicle activities and, in this discussion, these are assumed as 
initial conditions that drive the sizing of the booster. 

The matrix in Figure 14 shows the discipline involved in the per- 
formance and configuration synthesis of the vehicle. These are 
flight mechanics /aeroballis tics , propulsion, guidance, flight 
controls, structures, and central systems engineering. 

These disciplines constitute a systems engineering team whose 
primary objective is to select a concept and size the performance 
of subsystems to achieve the best solution to the mission/payload 
requirements. 

Flight mechanics /aeroballis tics is the focal point or lead disci- 
pline. This discipline performs the initial analysis of the mis- 
sion to establish the performance requirements that must be satis- 
fied by the system, and as such performs a systems engineering func 
tion. These activities result in determination of the — 

1) flight path (trajectory) ; 

2) system accuracy requirement; 

3) energy requirement (Av) ; 

4) natural and induced environment. 

This mission problem analysis centers on a simulation of the 

mission that permits examination of performance parameters and 

system design characters. After initial mission requirements 

have been established, the next step is to examine the subsystem 

concepts and select, on the basis of performance capability, the 

configuration that meets the mission requirements. Where several 

concepts are being composed, performance data is developed in 

parametric form to permit selection of the candidate subsystem, 

(propulsion, for example) having the most benefit in terms of 1 , 

sp 

weight, state-of-the-art considerations, and cost. The initial siz 
ing of the vehicle results in parameters that provide the basis 
for subsystem definition. 

These parameters include — 

1) specific impulse of engines selected tentatively for the in- 
dividual stages ; 

2) velocity requirement for the mission under consideration; 
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3) propellant fraction of individual stages estimated, based on 
the selected state-of-the-art, design features, and the thrust- 
to-weight ratio selected; 

4) payload ratios desired as target values, based on the theory 
of stage optimization; 

5) takeoff thrust, tentatively selected for the vehicle under 
consideration; 

6) takeoff acceleration selected with consideration of performance 
and launch dynamics. 

As shown in Figure 16, the objectives of the next phase of per- 
formance analysis is to develop preliminary weight breakdown, net 
payload capability, and vehicle performance parameters. 

The stage specific impulses and the velocity requirement result 
in an overall effective mass ratio. Propellant fraction and pay- 
load ratio result in an average structural factor. This and the 
total mass ratio result in the optimum number of stages required, 
and give a first estimate of the growth factor (takeoff weight/ 
payload weight). Combining this with the takeoff acceleration, 
gives a first estimate of the total weight-carrying capability 
(weight of instrumentation, guidance and control components, pay- 
load container, and net payload), defined as the dry gross payload. 

A preliminary optimization of the propellant loadings of the stages 
which in turn allows more detailed weight estimates of the subsys- 
tems and components follows. 

The flight mechanics/aeroballistic discipline performs the lead 
system function in initial sizing, which is one aspect of the sys- 
tem operational analysis of the definition/design phase. The 
subsequent verification of definition phase results involves an 
expansion of the simulation model to take into consideration 
structural characteristics (loads). When this verification of 
primary performance has been made , preliminary design of vehicle 
subsystems can be performed. 

In summary, the flight mechanics discipline functions as the lead 
in the performance sizing and optimization of the vehicle system. 

In this capacity the requirements for propulsion, guidance, flight 
control structure, and mass properties of vehicle and payload are 
brought together and resolved into a compatible set of require- 
ments that meets the mission requirements. This discipline per- 
forms the following systems engineering functional activities: 
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1) Act as lead discipline in defining the mission flight path and 
sizing of performance requirements for vehicle subsystems. 

2) Develop simulation model of the system performance in all mis- 
sion states. 

3) Determine vehicle system performance requirements (AV, accuracy) 
for the payload /miss ion. 

4) Determine environments resulting from the system's interaction 
with atmospheres and planetary physical properties. 

5) Provide the simulation module for examination, sizing, and 
optimization of vehicle performance parameters. 

6) Evaluate performance effects on payload. 

7) Determine performance capability margins. 

8) Provide the means for vehicle system loads determination. 

9) Provide the means for determining stability and control char- 
acteristics and requirements. 

10) Specify the coordinate system flight mechanics models, com- 
puter programs , language atmospheres models , to be used in 
performance analysis of all system elements. 

11) In conjunction with system safety, provide performance analy- 
sis of abort and hazard conditions. 

12) In conjunction with structures discipline, perform staging 
analysis. 

13) Define reference trajectory to be used for system definition/ 
design. 

Proj^utston ( Figure 14 j Item 2 ) - The propulsion subsystem provides 
the thrust energy necessary to achieve required flight path tra- 
jectories and to control the vehicle orientation and attitude dur- 
ing the mission. The propulsion subsystem is integrally related 
to a number of other vehicle subsystems and must be considered in 
the sizing of these subsystems. It is because of these interrela- 
tionships and interfaces with other subsystems and the criticality 
of the propulsion subsystem to mission success that the configura- 
tion of the propulsion subsystem is a systems engineering activity. 
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The primary impact of the propulsion subsystem upon the design 
(performance) of other subsystems is on the vehicle structure and 
flight controls. The structures subsystem provides the structural 
support to house the propulsion subsystem and, more importantly, 
adequate structural rigidity to transmit propulsion force along 
the directional axes, while staying within tolerance for distortion 
and bending moments. 

The flight controls subsystem is dependent upon thrust (thrusters) 
provided by the propulsion subsystem to control the attitude of the 
vehicle as well as the line of thrust when the main engines are 
firing. The systems engineering functions that are performed dur- 
ing the development program follow. 

1) Determine the program schedule milestones such as integrated 
testing schedule, hardware delivery schedule, etc. This will 
affect the selection of the propulsion concept because major 
components of some concepts may require new technology or 
requalification. 

2) Establish mission success criteria and operational safety 
requirements. This impacts the propulsion concept selection 
by indicating the type of components that the selected subsys- 
tem will require, level of redundancy, safety factors that must 
be met, and at various stages of subsystem development, test 
requirements to verify that the all requirements are, in fact, 
being met. 

3) Develop specific functional performance requirements for each 
of the mission states. This affects component criteria and 
selection, and the subsystem development and qualification 
test requirements. 

4) Determine external environmental levels in terms of pressure, 
temperature, and radiation that must be considered during the 
propulsion subsystem selection and development- 

5) Establish physical envelopes and mechanical and electrical 
interfaces that will impact the propulsion subsystem selection. 

6) Determine GSE and facility requirements. 

7) Identify alternative propulsion concepts and configurations 
that meet the mission requirements. 


8) Perform trade studies and select a single propulsion subsys- 
tem concept. 

9) Analytically verify that the propulsion subsystem will pro- 
vide the energy required for the mission. 

10) Integrate the subsystem preliminary design with other vehicle 
subsystems and system elements. 

Flight Control ( Figure 14, Item 3) - The flight controls discipline 
is responsible for conceiving and designing systems for control- 
ling the flight path and attitude of the vehicle as dictated by the 
guidance subsystem. This subsystem is closely correlated with 
guidance, propulsion, and vehicle structures performance, and be- 
cause of this the analytical design of the flight controls is a 
systems engineering activity. The purpose of the flight controls 
system is to transform guidance commands into usable steering 
commands to control forces and to stabilize the rigid-body dyna- 
mics of the vehicle without exciting other vehicle characteris- 
tics that could produce excessive loading conditions. 

During early conceptual studies, the design effort is aimed at 
selecting a type of system that meets mission requirements. Once 
the vehicle configuration, propulsion, and aerodynamics of the 
system have been determined, the rigid-body mode is Analyzed and 
the constant gain configuration that stabilizes the vehicle is 
determined. As the vehicle structure definition proceeds and 
preliminary knowledge of the vehicle loads due to wind distur- 
bances, thrust misalignment, propellant sloshing, etc is obtained, 
an initial analysis of the stability and control problem is made 
and the hardware impact is incorporated in the flight controls 
design. 

The correlation with guidance, crew operations, propulsion, and 
electrical sequencing systems includes both performance and de- 
sign considerations. The performance of these systems is inter- 
related in achieving a desired flight path trajectory and ac- 
curacy. This means that these systems describe a performance 
problem that must be solved as a combined effort of these disci- 
plines. Because of the interrelationship with these disciplines 
in achieving system performance capability, the flight controls 
concept, definition, and design is a systems engineering activity. 
The specific system functions for this discipline follow. 
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1) In conjunction with the mission performance and definition 
team, examine the mission modes and determine the flight team, 
examine the mission modes and determine the flight control 
steering stability and attitude requirements that must be met. 
This analysis establishes the specific problems that must be 
solved, first analytically with a control scheme and, secondly, 
with a hardware design that implements the scheme. 

2) Based on mission requirements, develop alternative scheme and 
hardware concepts, and describe them sufficiently to determine 
that each is feasible and will permit qualitative and quanti- 
tative comparison. The study criteria provides the selection 
criteria that identifies the system attributes and their rela- 
tive importance. 

3) Compile system design and performance requirements from cen- 
tral systems and other design groups applicable to the flight 
controls subsystem, and develop criteria for design definition. 

4) Develop performance and design interface definitions in func- 
tional form; where significant system impact is identified, 
develop design solutions. 

5) Support, as required, intercenter, intercontractor working 
groups for interfaces, crew/mission operation, verification, 
etc. 

6) Develop analytical methods and models to permit assessment 
and synthesis of design solutions for each mission state. 

7) Support configuration change board, program, and design re- 
view activities. 

8) Provide inputs to central systems for statements of work, out- 
put specifications DRL/DRD for each program phase. 

9) Implement system trade study requirements and criteria pro- 
vided by central systems and participate in system level trade 
studies where flight controls is a factor. 

Guidance (Figure 14 Item 4) - Guidance is concerned with the long 
range aspects of the flight path that an airborne vehicle must 
follow for a successful mission. The guidance discipline has the 
responsibility for defining the guidance and navigation require- 
ments for attaining these flight paths and then synthesizing a 
hardware and software solution that best meets these requirements. 
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This involves defining the mission flight path(s) , determining 
the navigational system (inertial, celestial, radio) to be used 
in determining methods of sensing flight path deviations and 
generating guidance command signals to activate the flight con- 
trol system. As shown in Figure 14, this discipline activity 
involves the requirements from other design disciplines and sys- 
tems engineering. The guidance solution must consider all of these 
requirements and satisfy them. The systems engineering functional 
activities can be classified in terms of system performance, 
requirements analysis, synthesis and integration. The first of 
these is the interaction of the guidance discipline in the mission 
analysis and determination of the guidance and navigation require- 
ments for system accuracy. The requirements analysis is the 
determination of the total system requirements that must be satis- 
fied by equipment and software provided by the guidance discipline. 
The systems engineering activities in synthesis and integration 
are those involving selection of a solution that best satisfied 
the mission/system requirements and integrating the guidance sub- 
system into the system. 

The systems engineering activities performed by the guidance disci- 
pline follow. 

1) As a part of the system performance team, determine the guid- 
ance and navigation accuracy requirements. 

2) Develop guidance law equations for candidate guidance con- 
cepts. 

3) Perform concept trade studies to determine mission feasibility. 

4) Collect /compile and analyze total mission/system element/sub- 
system requirements affecting guidance and navigation. 

5) Postulate design definition solutions to meet the system re- 
quirements. 

6) Perform trade studies using system selection criteria. 

7) Participate in system performance and design trade studies 
in which guidance is a factor. 

8) Support, as required, program and system design reviews. 

9) Participate in interface working groups and panels to assure 
the complete identification and solution of functional and 
physical interfaces. 
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10 ) 


Develop guidance error analyses to verify system accuracy 
capability . 

11) Implement documentation requirements defined by central sys- 
tems engineering. 

12) Provide inputs to statements of work, system specifications 
and development plans that affect guidance and navigation, 
performance, design, and verification. 

Structures (Figure 14 s Item 5) - The systems engineering func- 
tional activities of the structure discipline are to configure a 
structure that supports and houses the payload. There are two 
aspects of structures design that have system implications. These 
are configuration design and system performance. 

In the concept and configuration design phases, the structures 
group is the focal point for conceiving and configuring a struc- 
ture that in size, shape, and arrangement adequately houses and 
protects payload elements. The structures activities represent 
the design integration function that takes as inputs the estimated 
size and mass properties of payloads and system conceptual deci- 
sions, such as number of stages, and conceives a structural con- 
figuration that is feasible in terms of size, shape, and strength. 
The term payload is used in the sense that all subsystem elements, 
mission payload subsystem, and vehicle subsystems are all payload 
elements . 

The second system function performed by structures is to provide 
performance characteristics that are needed to size the system 
performance of other elements. The two system characteristics 
that impact system performance and the configuration of other 
elements are materials and loads. 

Materials - The materials to be used in the structural design of 
payload elements must be identified as early as possible in the 
development program. The characteristics of these materials must 
be determined and compared with system requirements in terms of 
strength, rigidity, combustion point, ability to sustain combus- 
tion, outgassing toxicity, conductivity, etc. If the material 
selected is not on the current approved materials list maintained 
by the contracting agency, then the material must be tested and 
proved to be safe and meet all requirements, or rejected and 
another material selected. 
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Loads - The development of structural loads characteristics is the 
last system engineering functional activity of the structures disci- 
plines . 

Loads may be classified in accordance with their origin or distri- 
bution. Body. forces are distributed within the volume of a body 
proportional to its mass. They are gravitational, magnetic, and 
inertia forces if the body is in accelerated or curved motion. 
External forces , such as thrust, pressure, lift, drag, support or 
bearing loads, shock and vibration forces, are distributed over the 
surface of a body. Internal forces are caused by nonlinear temper- 
ature distribution or nonuniform response to heating in structures 
with different materials, and their distribution depends upon the 
temperature and material distribution. 

Static or dynamic equilibrium and compatibility of displacements 
with geometry and boundary conditions are the basis of all struc- 
tural analysis. Stresses and strains in a body are caused by the 
difference in distribution or inertia or mass forces and external 
forces. If inertia and external forces are not balanced, the 
body changes either its velocity or its direction of motion or 
both. 

The stress distribution and intensity is a function of force dis- 
tribution and intensity, body geometry, temperature, and mate- 
rials. In some cases it is also a function of deformations caused 
by one of the above mentioned primary influences. The body, bent 
by nonuniform temperature distribution, changes local angle of 
attack, and thus the lift distribution. Furthermore, the thrust 
now acts on a curved beam, creating an overturning moment, and. 
Together with the eccentric inertia forces, also creates con- 
siderable bending moment over the entire body. This can lead to 
buckling of the missile as a free-free beam. 

During its lifetime, a space vehicle and its components experience 
a variety of loads: assembly loads caused by its own weight, 

thermal differentials, residual stresses from forming, machining, 
welding and milling; transportation and handling loads as well as 
the dynamic loads of flight. 

The structural loads analysis efforts is to provide structures 
characteristics in the form of — 

1) structural rigidity 

(bending modes frequencies and shapes and node locations with 
respect to control forces) ; 

2) propellant sloshing modes. 
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This is a basic systems engineering activity that provides analyt- 
ical data for vehicle control system design. The control system's 
task is to impose control moments on the vehicle in response to 
guidance commands and to resist disturbance inputs caused by aero- 
dynamic disturbances, thrust misalignment, etc. The objective of 
the automatic control system is to stabilize and provide attitude 
control of the rigid body dynamics of the vehicle while not excit- 
ing vehicle modes that could produce excessive loading conditions. 

3) Dynamic load stability analysis to include transient load analy 
sis at launch, ignition, and shutdown. At each point in the 
mission sequence, some of these properties are coupled mode 
shapes, frequencies, and damping; time histories of accelera- 
tions and beam load; time histories of model responses (model 
accelerations, velocities, and displacements); maximum and 
minimum load displacements and accelerations; statistical 
loads combination. 

4) Model analysis to evaluate the dynamic characteristics of the 
total vehicle to determine vehicle and payload transient re- 
sponse loads and flight control system stability. These param- 
eters Include uncoupled booster modes; coupled total vehicle 
modes; cantilevered coupled payload modes. 

In addition to the primary system activity functions of the basic 
structural loads analysis efforts, the following secondary support 
in the overall system design area is — 

1) determination of transport and handling loads; 

2) consideration of storage loads ; 

3) estimation of prelaunch loads ; 

4) analysis of launch loads ; 

5) reentry and recovery loads ; 

6) flight loads, including wind gusts. 

Once the preliminary loads on a vehicle are established, the de- 
sign process determines selection of materials, overall geometry, 
and detailed dimensions to properly transfer those loads or ex- 
ternal forces to equilibrate with the inertia reaction forces. 
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Thus, the main structural elements of the vehicle are defined. 

These are fuel tanks, engine, guidance and payload compartments, 
and transition members such as skirts, thrust mounts, brackets, 
and fitting to connect with the main parts. The main parts of 
the structure consist of elements such as tension ties, columns, 
beams, beam columns, trusses, and rings supported on an elastic 
foundation, and involving straight and curved panels and shells 
of various sizes. 

These basic elements are now analyzed and designed to carry the 
primary and secondary loads reliably, as well as to reduce ad- 
verse interactions with each other, in terms of body flutter, 
sloshing; vibratory, acoustic, and other dynamic and thermal 
effects. 

In summary, the systems engineering activities associated with 
the development of the vehicle structures follow. 

1) Perform an analysis of the structural requirements in terms 
of the payloads anticipated, the shape and configuration of 
the vehicle structure, and the sizing required. 

2) Develop alternative concepts of the structures configuration. 

3) Perform trade studies to select the structures concept. 

4) Identify the materials to be used in the structures design. 

5) Determine if the materials selected are on the approved mate- 
rials and parts list maintained by the contracting agency. 

If the materials are not approved, and cannot be because of 
safety or reliability factors, substitute materials must be 
selected. 

6) Develop structural loads characteristics of the structural 
configuration. 

Electrical (Figure 14 3 Item 6) - The electrical subsystem serves 
as a central switchboard to provide all power and switching func- 
tions to the various subsystems. As such, unnecessary duplication 
and lowered efficiency must be prevented through integrated de- 
velopment of the electrical subsystem. 
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From the initial subsystem identification, the subsystem designers 
designate functional requirements schematically, as well as pro- 
vide preliminary location and packaging requirements within the 
flight vehicle and associated support equipment. Primary concern 
at this point is to identify minimum essential requirements for the 
flight vehicle and necessary subsystem support functions to be 
provided through the support equipment. 

Following these initial steps by the individual subsystem engi- 
neers, the electrical systems engineer can initiate the electri- 
cal subsystem integration efforts. 

The common needs and interconnections from one subsystem to another 
should identify the electrical distribution system where all the 
functions are established, controlled, and distributed. Systems 
engineering here establishes itself as an efficient and essential 
part of the overall system, and a tool to assure the greatest 
flexibility for maintaining the latest design requirements. 

In forcing the design of each subsystem to reflect the primary 
vehicle mission, independent relays, sequences, and power sources 
can be eliminated and these essentials provided for all users by 
the electrical system. This will simplify almost every unit and 
permit the subsystem designers to concentrate on their primary 
task, assured that the primary power and sequencing functions 
will be provided. The electrical system's design will effectively 
combine all requirements and provide a flexible and efficient 
service to the total program. 

The interrelationship of the various subsystems dictates that the 
integration of all requirements into an electrical subsystem is a 
systems engineering task. The specific engineering activities 
performed during this task follow. 

1) Perform the initial electrical subsystem definition based on 
mission and other subsystems requirements. 

2) Combine the electrical requirements of each of the subsystems. 

3) Determine the operational sequences required by the mission 
and other subsystems. 

4) Prepare layout of the electrical distribution required. 

5) Allocate electrical limits to the subsystems. 
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6) 


Identify alternative concepts and concepts to meet the elec- 
trical requirements. 

7) Perform trade studies to select the electrical subsystem con- 
cept and configuration. 

8) Develop electrical subsystem design standards and criteria. 

9) Prepare end item specifications for the electrical subsystem. 

10) Perform integration activities. 

CoCTronicat-fons [Figure 14 3 Item 7) - The communications subsystem 
for a typical space mission consists of all facets of communica- 
tion between the spacecraft and ground stations, spacecraft to 
spacecraft to spacecraft, and intraspacecraft. This includes real 
time voice communication, television, telemetry, delayed trans- 
missions, taped data, filmed data, and stored data for return in 
the spacecraft. Typical data that may be communicated includes 
engineering data (housekeeping) , equipment checkout data, opera- 
tional data, hardware status data and crew data. 

The communications subsystem is greatly affected by the opera- 
tional concept and modes of the mission. For this reason, the 
mission concept must be clearly defined before the communications 
concepts can be defined and evaluated. 

The systems engineering activities performed during the develop- 
ment of a communications subsystem follows. 

1) Determine mission operational environments such as the atmos- 
phere (s) through which data must be transmitted, spacecraft 
orientations, length of mission, distance of mission, etc. 

2) Determine the requirements that the communi cat ions subsystem 
must meet to satisfy the mission such as: 

a) User Requirements — 

1) Engineering data (housekeeping) 

2) Checkout data 

3) Operational data — real time voice communication; 
experiment and spacecraft subsystems status. 
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4) Crew data 

b) What measurements are required 

c) How much data is required 

d) Accuracy required 

e) When is data required; real time or storage 

f) Data capacity — 

1) Seal time transmission 

2) Delayed time transmission 

3) Data rate - bits, symbols 

4) On-board processing — coding, storage, compression 
requirements, selection, scaling, data 

g) Environment 

h) Reliability 

i) Safety 

j) Power at frequency (command process) 

k) Antenna usage 

1) Antenna requirements 

2) Modulation 

l) Bit error rate 

m) Signal/noise 

n) Code 

o) Receiver characteristics 

p) Display 

q) Processing 

r) Power, weight, thermal model 

s) Cost 
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3) Determine the physical and functional interfaces that must be 
considered during the communications subsystem design. Deter- 
mination of interfaces may cover the interrelationships between 
all subsystems and disciplines. Lower level interfaces, such 
as connector-to-connector or pin-to-pin, are the responsibility 
of the design groups and are the concern of systems engineer- 
ing only as they affect, subsystem performance. 

4) Develop alternative concepts and configurations that will meet 
the requirements. 

5) Conduct analyses and trade studies to select the communica- 
tions concept and configuration. The trade studies are usually 
conducted by specialists in systems engineering, communica- 
tions design, and the other disciplines that are involved. 

One of the most important systems engineering tasks is to 
identify the analyses and trade studies that are to be per- 
formed and coordinating these tasks until completion. 

6) Select and define the communications subsystem based on the 
above analyses and trade studies. 

7) Prepare end item specifications. 

8) Perform preliminary design. 

ffnpironmentaZ Control (Figure 14 , Item 8) - As in other functions 
in central systems engineering, the definition and control of en- 
vironmental requirements is an activity aimed at achieving con- 
sistent and complete results that best meet the mission require- 
ments. The environments that have a significant bearing on the 
successful definition and design of a system follow. 

1) Natural environments that affect the system; 

2) Induced environments resulting from the system's interaction 
with the natural environment; 

3) Environment induced on one system by another; 

4) Environmental conditions arising from interaction of system 
elements. 

The types of these environments can cover a wide spectrum depend- 
ing on the mission, and the survival of equipments and crews re- 
quires a definition of these environments. Knowledge of environ- 
ments that exist or are propagated in each mission state; i.e., 
prelaunch, launch, ascent. Earth orbit, etc, is necessary in de- 
signing protection or control elements. Examples of environmental 
conditions that may be encountered follow. 
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Natural Environment 
Planetary 

Atmospheric (including wind loads) 

Thermal 

Gaseous content 
Gravity 

Radiation belts 
Magnetic fields 
Space 

Radiation 

Meteoroids 

Vacuum 

Induced Environment 
Dynamic 
Thermal 
Radiation 
Man 

Vibration 

Shock 

Humidity 

Thermal 

Radiation 

Acoustics 

Meteoroids 

The interactions that make up the systems environmental require- 
ments activity include — 

1) examination of the system element in each mission state; 

2) identification and quantification of applicable environments 
for each state; 

3) examination of system elements interaction with these environ- 
ments ; 

4) development of a design criteria to be used in the definition/ 
design of the system element; 

5) generation of data to define or refine environmental param- 
eters. 

In summary, the systems engineering environmental group is re- 
sponsible for environmental criteria tasks as follows : 
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1) Establish and maintain the program environmental design cri- 
teria, including thermal vibration, acoustics, shock, radia- 
tion, meteoroids, planetary environments, etc. 

2) Act as the single focal point for environmental criteria con- 
trol, specification, discussions, and presentations to customer. 

3) When the program environmental criteria includes analyses 
from other functional disciplines, thoroughly review, under- 
stand, and approve the input analyses. 

4) Assure that the rationale supporting each environmental defi- 
nition is correct and thoroughly documented. 

5) Verify environments with analyses and measurements as required. 

6) Establish conservative margins between actual conditions and 
design and test conditions. 

Groimd Support Equipment (Figure 14 , Item 9) - Ground support 
equipment is required to support all on-module and off-module 
activities from development testing through launch of the final 
program payload. GSE equipment takes the form of test tools, de- 
liverable GSE, and maintenance and handling equipment. Central 
systems engineering acts as the organizational focal point through- 
out the program to integrate all technical support requirements 
that require ground equipment, and to develop an adequate and 
cost-effective set of hardware and software to meet these require- 
ments taking into consideration the program constraints (i.e., 
cost, schedule, using locations, etc). 

Each of the design disciplines must identify the GSE requirements 
needed throughout the development and operational program. It is 
these requirements that dictate kinds and quantity of GSE required 
for the program. The specific systems engineering activities per- 
formed during the development of GSE follow. 

1) Develop the overall GSE philosophy compatible with the pro- 
gram. 

2) Establish the requirements for GSE. 

3) Scope the extent of the GSE task; i.e, number of end items, 
types of equipment, cost, schedule, etc. 

4) Develop a GSE requirements document. 
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5) Baseline a preliminary set of functional test requirements; 
i.e., pressurization, power, PCM format, data recording, leak- 
age checks, handling, alignment, etc. 

6) Develop alternative concepts to meet the GSE requirements. 

7) Perform trade studies of the alternative concepts consider- 
ing cost, development, commonality, existing equipment, and 
commercial equipment, utilization rates, using site compati- 
bility, flexibility, etc, to select the GSE concept and con- 
figurations. 

8) Define the selected concept and configuration. 

9) Establish the logistic support equipment configuration. 

10) Prepare GSE end item specifications. 

11) Establish design requirements and perform preliminary design. 

Facilities (Figure 14 , Item lOJ - Facilities encompass these 
ground based installations that are required for test, operation, 
maintenance, receiving and inspection, and launch area storage of 
flight hardware and associated ground support equipment (GSE) . 

The purpose of the facilities program is to assure that all re- 
quired facilities are available to the operating forces and sup- 
porting activities in a timely manner. Facilities planning is 
based on operations and maintenance analyses, equipment design 
drawings, specifications and other documentation necessary for 
defining types of facilities, locations, space needs, environment, 
duration and frequency of use, personnel interfaces, installation 
activities, training requirements, test functions, and existing 
facility applications. Facilities development requires integrated 
attention throughout all phases of the life cycle to provide posi- 
tive coordination with other program elements. Because of this 
integrated relationship, the selection of the facilities concept 
and configuration (s) is a systems engineering activity. The func- 
tional activities that are performed in the development of the 
facilities configuration follow. 

1) Define and evaluate facility requirements. 

2) Prepare facilities concepts. 

3) Perform trade studies to select the facilities concept(s). 

4) Perform facility sizing. 

5) Integrate the facilities preliminary design with other system 
and subsystem elements. 
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The definition of facility requirements mu9t be established as 
quickly as the determination of operational and support require- 
ments are known due to the lead time involved with procurement and 
construction of the facilities. Development schedules must con- 
sider construction delay experience on similar programs due to 
seasonal weather and other regional considerations such as labor, 
soil conditions, etc. 

The specific systems engineering functions that are performed 
during the development of the facilities configuration follow. 

Define and Evaluate Facilities Requirements - During the develop- 
ment of each of the systems elements , the requirements for facili- 
ties (launch, test, storage, etc) must be determined. 

Based on the required operational capability and the gross sup- 
port requirement, an analysis is made to determine what facility 
capabilities are needed. An integral part of this analysis is an 
assessment of facilities used to maintain similar systems and 
equipment. This action is based on available operational readiness 
performance experience data, gross system configuration and pre- 
liminary maintenance and maintainability assessments of support 
needs. The resultant estimates should define both existing facili- 
ties that may be used and those requirements needing further ex- 
ploratory study. Criteria considered in these evaluations in- 
clude — 

1) initial facilities tradeoffs needed to define basing, move- 
ment, deployment, durations and frequency, etc; 

2) ground rules for facility selection (e.g., considerations of 
required material resources by type, quantity, and location 
as well as construction force needs in terms of skills, 
numbers, and availability); 

3) constraints to be considered (e.g., security, easements, 
ownership, etc.) ; 

4) operations and support interfaces to be examined (tenancy 
concepts, deployment variations, combat contingencies, dura- 
tion differences, and primary launch, test or operating base 
complexes along with support shops, personnel, storage, and 
administrative requirements) . 
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Perform Facility Tradeoffs - System feasibility studies and sup- 
port element tradeoffs are evaluated for their impact on current 
facilities. Facility tradeoff studies are conducted to satisfy 
new requirements, and the best approaches are selected for review 
and consideration in the maintainability and reliability tradeoff 
studies. For example, the tradeoff studies may include considera- 
tion of alternative basing modes (e.g., hardened versus dispersed, 
mobile versus fixed, land versus water) , existing versus new 
facilities, different materials to be considered, and portable 
versus fixed power sources. 

The several support alternatives are evaluated and the most favor- 
able facility concepts selected for further study. Cost informa- 
tion, technical feasibility problems and high risk areas are identi- 
fied. 

Establish Facilities Concept - A facilities concept is selected 
on the basis of maintainability and reliability tradeoffs and 
system feasibility studies. This concept is reviewed for compati- 
bility with the maintenance concept, and is included in the sup- 
port concept formulation package as guidance for the facility plan 
requirements to be identified in the facilities plan requirements. 

Provide Facilities Plan Requirements - Facilities plan require- 
ments are prepared for inclusion in the logistics support plan re- 
quirements and the RFP. They include criteria for further develop- 
ment of — 

1) real estate and construction specifications; 

2) primary facilities such as materials, power and communications, 
water, access roads, and critical real property; 

3) support facilities for ships, personnel, training, storage 
transportation, and administrative use; 

4) critical research .and test needs; 

5) facility life cycle cost and budget estimates for the funding 
schedule; 

6) host-tenant agreements for support requirements. 
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Establish Facility Flan Evaluation Criteria - Technical and manage- 
ment evaluation criteria and interface control methods must be 
developed for determining the facility contractors’ responsive- 
ness to the general facility plan requirements and engineering de- 
sign specifications. As part of the overall support criteria, 
they include evaluation of — 

1) functional performance characteristics of supporting facilities 
(e.g., installed equipments' reliability, maintainability, 
useful life, environmental design and transportability) ; 

2) both general and definitive design and construction specifica- 
tions, standards, and constraints; 

3) detailed facilities concepts for nontechnical support (e.g., 
functional requirements, support policies , survival require- 
ments and policies, etc) siting and layout (e.g., area plans 
and site plans such as access, paving and drainage, contours, 
quantity-distance criteria, etc), and civil, architectural, 
structural, mechanical, and electrical requirements; 

4) funding, schedule, technical, and management control for 
those items requiring prototype construction and testing 
(e.g., critical Installed equipment and environmental control, 
electrical, power, missile launch suspension, and other simi- 
lar systems) . 

Integrate the Facilities Preliminary Design With Other System and 
Subsystem Elements - During the process of developing the facili- 
ties preliminary design configuration, the form, fit and function 
characteristics must be ascertained on a continuing basis, to inte- 
grate the facilities into the total system. This integration 
process must consider the requirements of other system elements 
such as payload, vehicle, and mission and crew operations as well 
as subsystem elements such as propulsion, structures, electrical, 
etc. 


c. 


This section has presented the systems engineering functions that 
are generally performed by each technical discipline in order to 
develop an integrated system, and a description of the system 
engineering activities performed within each technical discipline 
to develop subsystems that meet specific objectives and require- 
ments and, when integrated, result in a complete and optimized 
total system. Figure 14 shows, in matrix form, the relationship 
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between the function performed by a central systems engineering 
organization and the technical disciplines during the development 
process. Each of the examples of the systems engineering func- 
tions performed by the technical disciplines describes what the 
discipline is, the impact on the total system, the major inter- 
faces and impact on other subsystems, and a summary of the systems 
engineering functions performed by the discipline. 
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c. 


INTERACTIONS IN THE DEVELOPMENT PROCESS 


The previous sections were concerned with "what people and orga- 
nizations do" in describing the systems engineering technology. 

This description included consideration of the activities as part 
of each development phase, but an overview is needed to place these 
activities in the context of an integrated engineering operation. 

As pointed out, the development process goes through concept, def- 
inition, and design phases. These are natural states for system 
development, and it is possible to describe them as distinct ac- 
tivities as long as it is remembered that they are continuous and 
correlated activities. The departure point of one phase is not 
necessarily a hard breakpoint for the next phase activity. The 
tools (analyses, simulations, models requirements documentation, 
etc) are in process of continuous development; expansion and re- 
vision and the identification of the end of one phase and the 
beginning of another can only be considered as a rough division. 

The following sections describe the concept phase and the defini- 
tion/design phases in terms of major activities within which sys- 
tems engineering performs the functions described in the previous 
section. 

1. Concept Phase 

The purpose of the conceptual phase is to conduct the necessary 
mission and system studies and analyses, stimulate the need, ex- 
ploratory and advanced developments, and establish the economic 
technical and scientific basis for use in making a conditional 
decision to enter engineering development. When it is determined 
that there is a National Space Program need and technological 
basis to begin conceptual design of a system, the conceptual phase 
begins . 

Systems are visualized that may meet the operational requirement 
and may be within the technological state-of-the-art of the time 
period concerned. Whatever the initial mechanism, studies are 
conducted to develop conceptual systems to a point where the op- 
erational and technological functions and equipment for the system 
can be identified in some detail. 

Conceptual studies are concerned primarily with the feasibility 
of conceptual designs or approaches . The concepts are closely 
scrutinzed and analyzed to determine whether they are suitable, 
feasible, and acceptable, and the most preferred concept is se- 
lected. There are two general types of concept studies: 
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1) a broad-scope operational analysis type of study aimed at 
identifying the best general approach to fulfilling the 
objective; 

2) a system concept selection study that defines the general 
configurations of systems that could be developed and 
produced in the time period of interest. 

The output of this program phase is study results that: 

1) identify mission requirements to accomplish stated objectives; 

2) identify general system concepts and recommendations of the 
preferred approach based on performance and operational char- 
acteristics, and program requirements and constraints; 

3) define a set of performance and operational requirements; 

A) identify preferred subsystem concepts and general requirements; 

5) determine program milestones; 

6) determine gross cost estimates. 

Figure 17 shows the expanded functions that make up the concept 
phase. An examination of several conceptual phase efforts showed 
that the degree of detail varied widely from program to program. 

The variation was due in part to the nature of the conceptual 
effort. On programs that were "make from" existing systems, the 
results tended to be more definitive than conceptual definitions 
for which there was little related past experience. In other 
cases, certain functional areas were pursued to a greater depth 
because there is a strong inclination among engineers to do detail 
design or to jump to configuration decisions early in the develop- 
ment cycle. The results of this investigation have been normal- 
ized by referring to the- fundamental objectives of the concept 
phase and the descriptions of each function reflect what should 
occur. 

An examination of the functions in this phase showed that all must 
be classed as system engineering activities. As in any state of 
development, many different specialists are involved. The nature 
of the work determines whether their activities are slanted toward 
the total system or are aimed at the system elements level. All 
efforts in concept definition are focused on a system concept and 
determination of its feasibility to accomplish the mission objec- 
tives . 
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Figure 17 Concept Phase Functions 

















The following subparagraphs describe the functional activities 
of the concept phase with illustrations where needed to clarify 
the scope and content of functions. 

Block 1*1 (Fig. 18) Define Program* Technical Requirements and 
Cons traints - Prior to starting concept studies, it is necessary 
to analyze completely the nature and objectives of the required 
missions. The extent of mission definition provided will vary 
from program to program depending on the depth of earlier study 
efforts. 

Known constraints that have a bearing on ensuing mission function 
analysis and initial system concept should be clearly established 
in the study guidelines and requirements. 

This initial analysis includes an examination of systems that 
directly interface with or have a bearing on any system conceived 
to meet the stated objectives; i.e., a space rescue objective 
would require analysis of the system or systems served to deter- 
mine operational, performance, and hardware requirements that 
would govern the concept of a rescue mission system. If the pro- 
gram includes a requirement to use or modify existing system ele- 
ments, then these, too, would require analysis to identify the 
specific requirements that would form the basis for concept fea- 
sibility studies. 

This functional activity as a whole represents the statement of 
primary requirements for the concept studies. These data will be 
changed and expanded as the study proceeds, but in their first 
draft they constitute a statement of the problem and the primitive 
requirements and constraints. This is fundamentally a systems 
engineering activity with inputs from other disciplines as deter- 
mined by the particular objectives being examined. 

Block 1.2 (Fig. 18) Development of Alternative System Approaches - 
The activities in this function represent the initial system 
definition effort that leads to generating those alternative ap- 
proaches that will be presented as technically- promising concepts. 

The activity of creative development of ideas or concepts to meet 
the gross mission requirements is performed in a number of steps, 
depending on the complexity of the mission. Generally, the project 
and system management define the states in terms of gross functions 
and identify the types of systems that could accomplish the mission 
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Figure 18 Vehicle Control System Performance Model 











The types of scientific and engineering skills are identified and 
assembled into teams to study the states or mission phases. To 
give an example, an objective to perform a space rescue includes 
launch, attaining required flight path, docking and transfer, 
returning to Earth. These, states, the functions associated with 
each, and pertinent mission requirements, would define teams that 
would look for feasible system concepts. 

Systems engineering activity leads each team of specialists to 
assure all concepts adhere to mission requirements, functionally 
integrates the study elements in each team, and achieves communi- 
cation and compatibility between the various teams. 

The activity begins with a detailed analysis of mission objectives 
and constraints to achieve complete exposure and detailed amplifi- 
cation of the problem. This task may require the development of 
a series of models to depict functions of achievable alternative 
technical approaches for accomplishing the mission. Each of these 
competing functional approaches is then analyzed in detail to 
determine the relative probability that performance requirements 
of the mission will be attained. 

These alternative technical approaches are studied to translate 
objectives into performance requirements, constraints, and iden- 
tification of major barrier areas as criteria for conceptual 
design of the system, subsystems and segments. The function 
performance requirements are documented in terms of inputs and 
outputs, environments, performance, time constraints, etc, in 
sufficient detail to identify types of subsystems required. These 
subsystems would, in turn, be studied to identify the concept 
that would prove feasible for those selected parametric data that 
are developed for use in examining the system performance for 
each concept. 

Block 1.3 ( Fig , 18) Develop System Selection Criteria - Since the 
object of this program phase is to identify alternative concepts, 
determine their feasibility, and select those that show the great- 
est program and technical merit, a decision criteria is needed. 

The relative value of various factors must be established as a 
means of determining the candidate concepts that have the greatest 
overall merit. This activity becomes relatively simple when there 
is only one overshadowing parameter such as total acquisition or 
total life cycle cost. However, when technical risk, development 
time, payload capability, duration of mission become important, 
priorities and a formula for assessing total* worth may become 
needed. This functional activity represents the development of 
such information to be used in trade studies to identify recom- 
mended concepts. This activity is a systems engineering function. 
The approval of project management is required to assure that 
those responsible for decisions made in the course of the study 
concur with the criteria. 
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Block 1.4 (Fig. 18) Develop Operational Scenario - The study teams 
described in the previous function were concerned with concepts 
that could accomplish the mission. These teams also develop op- 
erational scenarios or profiles aimed at describing the way those 
concepts would work in performing the mission. These studies con- 
ceive of operational modes for time usage of system elements to 
accomplish the objectives and meet mission requirements; i.e., 
if a rescue mission has a reaction time requirement, then the 
readiness state must be examined and concept of operations to- 
gether with performance requirements that meet the operational 
need. 

The development of operational concepts and requirements addresses 
the availability, dependability, and verification aspects of mis- 
sion requirements, whereas the conceptual studies aimed at con- 
ceiving system approaches (Block 1.2) were concerned primarily 
with capability objectives and requirements. These aspects en- 
compass such scientific and engineering disciplines as logistics, 
reliability, maintainability, safety, test and checkout, facilities 
and specialists unique to the mission and system under considera- 
tion. Among these latter might be medical, crew geologists, etc. 
The steps in developing operational profiles and requirements in- 
clude : 

1) identification of the primary states and the associated mis- 
sion requirements ; 

2) postulation or conception of alternative functional sequences 
for each state; 

3) development of performance requirements in the form of para- 
metric data for each function. 

As this activity is a part of the synthesis of alternatives, it 
is an integral part of the work of study teams formed to perform 
the concept feasibility effort. Systems engineering defines the 
specialists required , develops the study plan and integrates the 
activities of the various specialists involved. Where mission 
requirements are changed or expanded, systems engineering coordi- 
nates these revisions throughout all study activities to assure 
that consistent alternative approaches are developed. 

Block 1.5 (Fi£_, 18) Develop To£ Level Functions - As system con- 
cept, operational modes, and scenarios are developed, the primary 
functions that must be performed to accomplish the mission are 
identified. This block represents the compilation of these func- 
tions for each of the alternative concepts, and correlating ap- 
plicable mission requirements with each function. This step is 
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the initial functional analysis that will continue throughout the 
development process. The purpose of this activity is to assure 
an orderly examination of the total mission and system elements by 
all members of the study team. The resulting information serves 
the function of giving systems management and the project an over- 
view of the total mission in functional form, and permits examina- 
tion of the proposed concepts for completeness and assessment of 
the compatibility of various facets of the conceptual design. 

These functional data are particularly important to operational 
concepts that address reliability, crew, maintainability, support, 
safety, etc, since these are not always described in as precise 
mathematical terms as are performance capability parameters. 

Functional requirements of each system concept of the alternative 
technical approaches are depicted for all operational modes of 
usage in all specified environments. Each function is described 
with statements of beginning/end conditions to include inputs, 
outputs, and interface requirements from intrasystem/intersystem 
viewpoints. Functions are defined to assure indenture as part 
of the largest functions and arranged in their logical sequence 
so that any specified operational use of the system can be traced 
within the closed- loop cycle. Alternative operational cycles are 
also identified. When more than one system concept is evaluated, 
each is depicted and identified as above. Records are kept to 
reflect the rationale for acceptance or rejection of each alter- 
native to permit traceability. Similar functions are cross- 
referenced to assure a common synthesis solution. Gross functions 
of each system concept are developed in sufficient detail to dif- 
ferentiate those performed by the system from those to be performed 
by subsystems. During this iteration all functional cycles (op- 
eration, maintenance, test, production, activation) are considered. 
While a detailed analysis cannot be made this early for all these 
functional cycles, concepts for all cycles are identified and 
described. Initial determination of skill levels and training 
requirements are identified and described. 

The task of development of this functional analysis data is per- 
formed by the members of the study teams and is led by central 
systems engineering personnel. 

Block 1.6 (Fig. IB) Bsvela^ Enm^nmental Criteria - As each mis- 
sion state is defined and as system concepts are conceived to 
operate in these states, the natural and induced environments 
are defined. This function represents the definition of these 
environmental data into basic criteria to be used in the evalua- 
tion of alternatives. The activity starts with the identification 
of the mission. states. Studies are then initiated to define the 
natural environments within which all system elements will operate. 


99 


Such factors or ground winds, winds aloft, atmospheric properties, 
temperature ranges, humidity, etc, must be defined to serve as a 
basis for defining technical approaches and the reference conditions 
for comparing alternative concepts. There is a close relationship 
between the attributes, capability, availability, and dependability 
of concepts, and the environment. These functional activities are, 
therefore, highly iterative. As an example, the derivation of a 
statistical model of the Mars atmosphere influences the descent 
and loading profile and concepts of system elements for accomplish- 
ing these functions. The folloiwng is a representative list of 
the types of environmental criteria that may be involved in a sys- 
tem development. Not all of these are required to be defined in 
the concept phase since the extent of environmental information 
is greatly affected by the level of detail of mission and system. 

The system engineering task is to determine the requirements to 
realistically examine the feasibility of the system and operational 
concepts. 

Block 1.7 (Fig* 18) Evaluation of Alternative Technical Approaches - 
Alternative technical approaches are evaluated in an iterative 
process that compares functional approaches against mission re- 
quirements, and the relative achievability and potential effec- 
tiveness of the alternatives. 

In this step, the evaluations performed are normally limited by 
factors such as the depth of available background materiel and 
limitations in time, money, and study resources that affect the 
effort. A primary factor limiting the scope of evaluation is 
that it must be confined to data that is required to identify 
technical approaches. 

The total system performance is assessed analytically by combing 
the performance characteristics of various system elements in a 
model (Fig. 18), performance can be compared to mission require- 
ments to determine feasibility. In the concept phase, the models 
are simple parametric analyses based on estimates of element per- 
formance. Elements contributing to a vehicle capability might 
be size versus thrust, thrust versus weight, thrust versus cost, 
etc. These data for alternative types of concepts show the prime 
performance characteristics in terms of other program and perfor- 
mance variables. The system model brings together these factors 
to verify the integrity of combinations of elements and their 
compatibility with mission and program constraints. This shows 
a typical control system performance model for a vehicle system. 

The model brings together propulsion, guidance, flight controls. 
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and trajectory concepts for evaluation. The gross system concepts 
of other subsystems such as electrical, communication hydraulic 
structures, etc, are represented as weight. Exercising this model 
will show feasibility and will also yield comparative data to 
select the most promising concepts. At this stage of development, 
the estimates of performance are highly uncertain and the feasibil- 
ity must include determining reserve capability. The cumulative 
effects of dispersions and nonlinearities are unknown, and so re- 
serve or margin are important factors in determ i ning feasibility. 
These are identified and expressed in such terms as A velocity, 
weight, etc. 

These performance evaluation, together with similar assessments 
of operational performance, constitute the system trade studies 
to compare alternatives. These analyses make the comparison in 
terms of : 

1) overall configuration and equipment arrangement drawings 
(details of structure and equipment sufficient to show 
feasibility) ; 

2) estimates of loads and load paths (size of major structural 
elements and selection of materials); 

3) estimates of weight, center of gravity locations, mass 
moment of inertia, etc, where applicable; 

4) gross mission requirements, parametric analysis, environmental 
profiles, crew size, mission duration and physiological 
requirements, performance, flight mechanics, gross cost and 
mission effectiveness analyses (Present data parametrically.); 

5) interface requirements and major technical problem areas; 

6) parametric data and tradeoff between various subsystem con- 
cepts (i.e., fuel cells, batteries, solar cells, etc); 

7) preliminary estimates of mission success, crew safety, and 
reliability appointments among subsystems; 

8) experiments and support equipment grossly defined and inte- 
grated. 

Iteration in the study is accomplished as required to change, 
clarify, extend, and evolve alternative technical approaches into 
conceptual candidates. All reasons for decisions are carefully 
documented to permit traceability in follow-on system engineering 
activities. 
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This step is completed when all approaches have been evaluated and 
narrowed to those that appear to be technically most promising. 

The depth of evaluation at this time must be in sufficient detail 
to permit the preparation of a development plan. 

The systems engineering activity is to perform the evaluation of 
the various parameters, apply the selection criteria to these data, 
and document the findings in system concept trade studies. These 
trade studies will identify all of the technical approaches eval- 
uated, those eliminated as unfeasible and those deemed feasible 
and recommended for further study. Both quantitative and qualita- 
tive comparative data are presented to show the basis of selection. 

Those alternative technical approaches that survive this initial 
iterative system development phase are presented in the study 
results. The technically promising alternative approaches are 
graphically portrayed using a task analysis diagram supported by 
brief specific narratives describing work to be done sequentially, 
work to be done in parallel approaches, major technical barriers, 
cost estimates, estimated time required to meet objectives, prior- 
ities of approaches, critical performance parameters, and probabil- 
ities of technical success for each approach. 

Configuration Definition 

This effort involves detailed study, analysis and preliminary 
design of each alternative system concept. The object of these 
studies is to select a single system approach from those identified 
in the concept phase. These studies are based on mission require- 
ments and constraints identified in initial conceptual studies, 
as well as the program and technical ground rules and constraints 
added at the beginning of the def ini ti on /design activity. The 
conceptual approaches shown to be feasible are subjected to capa- 
bility, operational, and verification analyses to establish a 
system configuration design for each alternative. These studies 
encompass : 

1) refinement of selected alternative concepts; 

2) preliminary system design data (including preliminary systems 
specifications) ; 

3) preliminary assessment of manufacturing and testing facilities 
and techniques; 

4) identification of systems requirements for launch and opera- 
tional support; 
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5) system and subsystem design-margins/safety-factor goals; 

6) preliminary reliability assessment, requirements, and plan; 

7) preliminary quality assurance plan; 

8) preliminary test plan; 

9) identification of advanced research and technology and 
advanced development requirements. 

The primary functions that take place in definition/ design are 
fundamentally the same as those in the concept analyses, since 
the engineering process of conceiving elements to perform func- 
tions that accomplish mission requirements does not vary. This 
design process results in sizing of system elements and verifica- 
tion by more detailed analyses of performance and operational fac- 
tors. Figure 19 shows the functions that make up the definition/ 
design effort and the activities associated with system element. 
Following is a description of those steps in the definition/ design 
phase of systems development process. 

Block 2 . 1 (Fig. 191 Sj2jd}L ~ The first activity in this 

phase is the management function of planning, organizing and 
staffing the study team. Each organization involved in the def- 
inition/design phase will have participated in concept studies 
or performed equivalent studies to provide the same insight and 
understanding of the development problem. Therefore, the task 
for each organization is to expand the study team that performed 
the initial studies to permit a detailed configuration design of 
the mission, performance required, and system elements. 

The inputs to the system definition phase are mission requirements, 
alternative system concepts and program requirements and con- 
straints. Design decisions at the system, system module or sub- 
system levels will, in some instances, have been made in the con- 
cept phase. These decisions will appear in the study requirements 
documents as criteria. Other configuration decisions will have 
been left open and subject to selection in the alternative ap- 
proaches . 

This first step, therefore, is an analysis of the input require- 
ments and constraints to compare them with those used previously. 
The result is an adjustment in mission guidelines, evaluation 
models, and other factors previously used. 
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Block 2. 2 (Fig* 292 Program Requirements and Constraints - 

Based on analyses of study requirements, a study criteria is devel- 
oped to control the study effort. This criteria defines — 

1) selection criteria for trade studies; 

2) the list of trade studies to be performed; 

3) the baseline reference mission to be used for sizing and 
selection; 

4) definition of the mission and development states that must 
be studied; 

5) definition of the environmental criteria that must be expanded 
in the study; 

6) definition of performance and design margins to be employed; 

7) performance requirements from study guidelines; 

8) system description from study guidelines and concept studies; 

9) mission requirements from study guidelines. 

This criteria document is a systems engineering effort and is 
maintained (revised and expanded) as the study proceeds. It 
forms the basis for studies in various portions of the system/ 
mission definition and serves as a data book for accumulation 
of results. The latter purpose provides management visibility 
to the overall study results. 

Of the factors contained in the study criteria, the trade study 
criteria is of particular importance as it establishes the basis 
for decision-making during the study. In this criteria, specific 
operational areas of design features within which, or against 
which trade studies are to be made, are identified. Trade studies 
may involve revisions of system functions and performance require- 
ments that can result in revised configurations of the system or 
specific end items. 

Criteria for trade studies are expressed in terms of resources 
and system parameters. Examples of resources are funds, time, 
manpower, and skills. Examples of parameters are weight, mission 
length, reliability, maintainability, safety, vulnerability, and 
survivability. Criteria for measurement of system effectiveness 
are stated in quantitative terms where practical. 
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The criteria established for trade studies are related to the 
system measures of effectiveness with particular attention to 
"essential" and "desired" characteristics stated therein. Trade- 
off limitations are specified in relation to "essential" character- 
istics and performance requirements for operations, maintenance, 
test, production and deployment elements. 

Block 2.3 fFtg. 19)_ Develop. Operational Scenarios - Based on the 
study criteria, operational and mission functions and requirements 
are developed. 

The initial function analysis that was performed during concept 
formulation is now iterated and expanded to lower levels to reflect 
for newly acquired information and directed changes. This analysis 
includes consideration, maintenance, test, production, and deploy- 
ment functions to the level necessary to define concepts . A time 
requirements analysis is performed on time critical functions. 

Mission objectives and constraints are reviewed and reexamined 
in relation to higher and lower order systems. A series of pre- 
liminary functional models are developed on as many levels as 
necessary to depict reasonably achievable alternative functional 
approaches. Each competing functional approach is then examined 
in detail to determine performance requirements associated with 
its function and the documenting of these requirements in terms 
of inputs, outputs, environments, performance constraints, time 
constraints, etc. 

Block B4 (_ Fi <?. 292 Subsi£stem Definition - Each of the proposed 
alternative system concepts in the system development plan are 
expanded to acquire further understanding of functions, perfor- 
mance, design requirements and constraints. The impact of each 
proposed system concept on other elements of the total system 
are assessed, and these new concepts are used to expand further 
the functional model to identify lower indentured functions. This 
synthesis of solutions is accomplished only to a preliminary de- 
sign level sufficient to assess design risk and to estimate devel- 
opment cost and schedule. 

Schematics and layouts are used as tools to provide for visibility, 
traceability, and communication. They portray the functional and 
physical interfaces between system elements and aid in integrating 
performance requirements into specific system elements. 

Facility end items, such as elevators, cranes, ramps, environmental 
control systems, etc are identified particularly in the case of 
command and control centers, missile installations, fixed repair 
facilities, strategic communication systems, etc. 
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The number and kinds of personnel for system operation, maintenance, 
test, production and deployment are identified in gross terms. 

The facilities, personnel, training equipment, procedural data and 
periods of time needed for training purposes are identified in 
gross terms. Government furnished equipment (GFE) that consti- 
tutes constraints upon the system is identified. 

In cases where the new system is one which is evolving from a 
presently installed system, or from a combination of presently 
installed equipments or systems, the performance requirements 
may have been generated from a study of existing capabilities. 

In this case, use of the functional models is subject to certain 
modifications in that the scope of the existing system may be 
fixed by mutual agreement between the developer and the user. 

Block 2.5 (_ Fig . 192 Psvelo£ Envigon^ Criteria - As the devel- 
opment of system and mission information proceeds, the environ- 
mental definition is expanded from initial definition of natural 
and imposed conditions. These data are compiled from examination 
of the mission states and the system operating sequence in each 
state. Where conceptual studies were limited to preliminary as- 
sessments of environmental conditions, these definition analyses 
reflect a more detailed information based on better estimates of 
loads (thermal, shock vibration, etc) . More complete models are 
developed based on these loads to determine compartment environ- 
ments and the need for environmental control measures. 

Block 2. 6 (Fig. 192 Evaluation and Sizing. - Based -on expanded mis- 
sion and operational analyses and environmental data, operational 
and performance models are expanded to evaluate the system con- 
figuration designs. This functional activity is the sizing of 
subsystem parameters, and developing time sequencing of functional 
events. In the mission and acquisition states, models are devel- 
oped and exercised for: 

1) capability - vehicle performance; 

2) survivability - safety, life support, environmental control; 

3) dependability - reliability, performance and design margin; 

4) availability - readiness, launch on time, storage life; 

5) operability; 

6) transportability; 

7) producibility . 
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The mission problems expressed as the functions to be performed 
and the functional requirements are expressed analytically in time 
of the performance parameters of system elements . The models are 
exercised to size the performance requirements into a set of al- 
locations that satisfy the mission requirements, are feasible design 
requirements, and are optimum from a selection criteria point of 
view. These models are expansions of those developed in concept 
studies and new models developed to examine system aspects not 
previously examined. An example of this is the modeling of a 
launch vehicle performance capability. In early studies, a three 
degrees of freedom trajectory model provides sufficient visibility 
to determine feasibility of attaining a given payload-orbit capa- 
bility in terms of thrust, weight, accuracy, etc. In system def- 
inition, the model would be expanded to reflect a distributed body. 
Subsequently, in preliminary and final design the model would be 
expanded to six degrees of feeedom and dispersions of parameters 
used to refine the performance analysis of the systems ability to 
perform the mission. 

The basic elements of modeling of performance factors are the 
analytical expression describing the mission in terms of physical 
parameters such as time, energy distance, mass properties , environ- 
ments, geometry, etc. The resultant performance relates to per- 
formance parameters of subsystem elements of the system. The 
parametric data that feeds the system performance models are para- 
metric data resulting from performance analyses of the subsystem 
involved. These subsystem performance analyses are also perfor- 
mance models for the concepts previous studies have shown feasible. 
In the example of a launch vehicle sited above, some of the sub- 
system performance models would be: 

1) guidance - guidance equations and error analysis; 

2) propulsion - performance model and error analysis; 

3) structure - load analysis; 

4) aerodynamics - aerodynamic equations - heating analysis. 

Block 2.8 ( Fig . 19) Perform Preliminary Design - Once systems 
performance analyses and determination of allocations to subsys- 
tems is accomplished, the selected system element and subsystem 
concepts are expanded to a preliminary design. The preliminary 
design is a detailing of each system element and subsystem in 
terms of configuration, function, design characteristics, and 
interfaces . 
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Preliminary design is aimed at describing the hardware, defining 
design and functional requirements and describing functional and 
physical interfaces. The input, in each case, is the system per- 
formance requirements. The factors listed above describe all 
factors that must be considered in preliminary design. Each of 
these factors is described below to show the data developed in 
preliminary design. 

Configuration - Size, weight, equipment elements, outboard profiles, 
location interrelationship of elements, materials, construction 
methods, arrangement of elements. These are described in block 
diagram, schematics, arrangement drawings, isometric drawings, 
layouts. 

Functions - Operating description, sequencing, mission modes, power 
requirements, environmental conditions, method of checkout, veri- 
fication methods, measurement lists. These data are in the form 
of operating descriptions, timelines, logic diagrams, performance 
parameter profiles, functional descriptions and functional require- 
ments . 

Design Characteristics - Reliability allocation, safety criteria, 
maintainability, allocation, design margins. These are described 
in terms of numerical values. 

Interfaces - Functional and physical interfaces with other subsys- 
tems and modules and other system segments covering mechanical, 
electrical, environmental, operating, handling. These data are 
described in preliminary interface documents which contain descrip- 
tions, parametric data, parametric value, arrangment schematics 
and drawings. The interface definition is the identification of 
complex interrelationships between fundamental building blocks, 
subsystems, and all other elements of the system. The total 
system can usually be defined in descending sets of complex ele- 
ments as in Figure 20. 

The interfaces of a subsystem are the sum total of its interrela- 
tionships with all other subsystems and elements. Preliminary 
design must develop (identify and quantify) these interfaces. 

Where quantification is not possible, because of lack of informa- 
tion, the minimum requirement is the definition of the functional 
interface. The decision as to whether any interface can be left 
in functional requirements form or should be carried to a solution 
is dependent on its impact on the system definition program cost 
and schedule. 
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Total System 



System Elements 


Figure 20 Total System 

If a particular parameter has significant bearing on performance 
of either a major system element or on other elements, it would 
be quantified. If the sizing of the interface has significant 
cost impact to the agency or contractor performance of the devel- 
opment of a system element then, too, it should be quantified. 

In subsequent steps of system definition and design, these inter- 
faces are defined in ICDs at various levels, i.e., module to 
module, system element to system element, and system to system. 
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Block 2j_8 (Fig, 192 QS2Sl£2. Breliminaxu Specifications - Prelim- 
inary system design data for the system and each system element 
is the primary technical output of the system definition phase. 

These data are combined at various levels of complexity to provide 
a coherent set of performance and design specifications of the 
system and its elements that have been conceived, configured, and 
sized to meet the mission requirements. The system definition 
results in a definition of the minimum set of specifications suf- 
ficient to describe the system configuration and the "design to" 
requirements for each element. The hierarchy of specifications 
needed to give a clear picture of a system depends on the com- 
plexity of the subject system. In general, a top system specifi- 
cation and a system specification for the major systems will be 
required to describe the system performance and design requirements 
that have been derived during this study phase. 

Since system definition may involve study of more than one concept- 
ual approach, the configuration design of each concept will result 
in system specifications. These will provide a basis for compar- 
ison and selection of the most promising concept. 

Block 2.3 (Tiff. 192 Bevel£2_ Plans - The results of the definition/ 
design activity are definitions of equipment, facilities, personnel, 
software, a functional description of how they work to meet derived 
mission requirements. The elements needed to perform the mission 
are described in preliminary specifications and in plans . Plans 
document actions required to implement the requirements derived 
during the system definition and design phase. Examples of these 
documents are the reliability plan, test plan, quality assurance 
plan, logistics plan, and configuration management plan. Each of 
these plans will include the following types of information: 

1) related organizations and responsibilties ; 

2) methodology - methods and procedures to be employed; 

3) means for review and controlling the activities; 

4) identification of coordination and control of various 
organizational activities; 

5) reports and documentation to be used; 

6) milestones and schedules; 

7) identification of support and facility requirements needed 
to implement the activity; 
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8) flow charts identifying the sequence of events; 

9) description of detail approaches to be employed for each 
major activity; 

10) identification of criteria to be used in performing the 
functions and judging performance; 

11) records, data, and approaches required in performing the 
functions. 

These data for each of the plans listed above describe "how" the 
function will be performed. 

3. Summary 

In summarizing, this section has presented a view of systems engi- 
neering in terms of the integrated activities that make up each 
phase. This description emphasized two things. The systems 
engineering objectives are accomplished by a strategy that involves 
control integration and evaluation of the technical efforts of all 
disciplines. The composite of the activities described in Section 
V.B are planned so that the result at the project level constitutes 
a technical requirement management to assure that results are 
stated and maintained as a consistent set of things. The second 
point emphasized in this section is that the process of development 
is not a set of distinct and separate phases, but is a continuous 
evolution to greater and greater detail requirements and descrip- 
tion of the system. Phase definition for contractual purposes is 
not necessarily an accurate description of the degree of system 
definition. 
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SYSTEMS ENGINEERING OPERATIONS 

In the previous sections, the description of systems engineering 
was treated in terms of roles and responsibilities and develop- 
ment process activities. This treatment addressed the interre- 
lation of systems engineering with elements of the system and with 
stages of development. These sections, B and C, described a three- 
dimensional condition, two at a time; the three factors are sys- 
tems engineering activities, systems elements, and system devel- 
opment activities (in time). This concept of the problem is shown 
in Figure 21 with the interactions described in previous sections 
identified. These three planes were covered separately to give a 
clear picture of each of the factors. The folding of these three 
views of systems engineering on a single plane is desirable because 
it gives a composite view with respect to time that is important 
to understanding system engineering functions. 


Program 

Phases 
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Engineering 

Functions 


Equipment A/B 



Procedures 


Figure 21 System Engineering Interactions 






Figure 22 shows a composite set of activities that occur during 
the definition/design phase. In this figure, the interaction of 
central systems disciplines and technical disciplines is shown 
at each point in the development process. The most important 
feature shown in the figure is the system requirements and defini- 
tion baseline that drives the development process and represents 
the baseline control of system requirements. As can be seen, 
this baseline is a source of requirements at each point in the 
development process and is continuously updated and maintained 
as decisions are made. The requirements baseline in Figure 22 
is identified as a heavy dark line near the top of the diagram. 

Figure 22 is an over simplification in the sense that, as a single 
view, it implies no organizational complexity. In practice, there 
would be a series of parallel flow charts for a multiorganization 
program, each addressing its portion of the program and its inter- 
faces with other segments. This composite diagram demonstrates 
the complexity that exists within a given system element as well 
as between system elements, and shows the need for continuous 
involvement of central systems engineering and the disciplines 
it represents to emphasize the total system. 

In the following discussion, the activities of Figure 22 are 
identified and described. In the horizontal axis, the require- 
ments, disciplines, activities, and system elements are identi- 
fied as follows: 

A. Central Systems Disciplines; 

B. System Integration Requirements; 

C. Technical Disciplines; 

D. Activities; 

E. System Elements . 

These activities are interrelated as will be seen upon examina- 
tion of the diagram, and the output of one activity affects the 
performance of another activity. This emphasizes the importance 
of the system requirements baseline that drives the development 
process and provides baseline control. It is the central source 
of requirements that affects all elements of the system. 


114 













DETERMINE 

general test 

PHILOSOPHY 





MAI NT CREW 
OPERATIONS CREW 


0 




















12 


13 


15 


PERFORM 

OPERATIONS 

SIZING 


A/8 EQUIPMENT 
DESIGN DEFINITION 


PrtfORM 

SYSTEMS 

REVIEW 


GSE & FACILITY 
CONCEPT DEFINITION 


ii. 


GSE & FACILITY 
CONCEPT EVALUATION 
& SELECTION 


17 


GSE & FACILITIES 
PERFORMANCE 
DESIGN ANALYSIS 


! 





ATIONS TRADE STUDIES 
ES POLICY 

(SPORTAT I ON ANALYSIS 
TY CRITERIA 
TENANCE POLICY 
TAXABILITY CRITERIA 
NDANCY 
S SELECTION 
JLE LIFE CRITERIA 


•CONFIGURATION ARRANGEMENT 
• DEFINITIONS 

{ DESIGN PERFORMANCE ANALYSES 
DESIGN REQUIREMENTS DEFINITION' 

• DESIGN FUNCTIONAL- ANALYSIS 
• INTERFACE FUNCTIONAL DEFINITION 
•RELIABILITY ASSESSMENT EVALUATION 
• PRODUCIBILITY analysis 







•EXAMINE REQUIREMENTS •EXPAND TEST & GROUN 

• SELECT ALTERNATIVES •EXPAND GSE PERFORMA 

• EXPAND CONCEPT DESCRIPTION •EXPAND DESIGN FUNCT 

• PERFORM TRADE STUDIES 
•SELECT PREFERREp APPROACHES 













18 


19 


GSE & FACILITIES 

PERFORMANCE 

SIZING 


GSE & FACILITIES 
DESIGN DEFINITION 


A/B EQUIP DESIGN 
DEFINITION UPDATE 



REQUIREMENTS 
& DEFINITIONS 
REVIEW 




D OPS REQ'S 
MCE MOOELS 
IONAL MODELS 





DESIGN 

CRITERIA 





• trade studies 

• ALLOCATION OF PERFORMANCE REQUIREMENTS 




MODELS EXPANDEO 


MODELS EXPANDED 






OEF IN I T I ON/DES I GN 
PHASE ACTIVITIES 
FIGURE 22 



















The vertical axis of the diagram shows events that occur during 
the development process, and the inputs and outputs of these events 
in or out of the requirements baseline. The diagram will be de- 
scribed in matrix fashion, i.e., line A, event 1; line A, event 2; 
line B, event 1; and so on. Initially, the requirements from the 
previous phase must be determined and distributed to all concerned 
during the definition/design phase. 

1. Initial Systems Analysis 

The first event is the initial systems analysis of the input re- 
quirements to aid in selection of the concept for airborne equip- 
ment (E-l) . This is performed by the central systems disciplines 
as shown in B-l, and by the technical disciplines shown in C-l. 

The activities performed are those shown in D-l. The results of 
these activities are inputs to the requirements baseline of cen- 
tral systems engineering (A-l) . 

2. Requirements Integration 

After the Initial systems analysis of the input requirements has 
been completed, the results are integrated into systems require- 
ments to determine the concepts selected for airborne equipment. 
The requirements integration event is shown in B-l. 

3. Concept Definition 

The alternative concepts for the system elements are fully de- 
fined so that selection can be made. This is shown in event 
C-3. 

4. Concept Evaluation & Selection 

Once the alternative concepts have been fully defined, they are 
elevated by central systems engineering and the best concepts 
for A/B equipment are selected (B-4) . The activities involved 
in the evaluation process are shown in D-4. The concepts se- 
lected are then integrated into the requirements baseline (A-4) 
and the system element line (E-4) . 

5. Performance and Design Analysis 

After the A/B equipment concepts have been selected, a perfor- 
mance and design analysis is performed by the central systems 
engineering and technical disciplines (B-5 and C-5) . At the 
same time, the systems design and integration discipline performs 
an integration activity of the performance and design analysis 
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results to assure that the concepts meet total systems suitability 
(B-5) . These analyses and integration activities result in an 
expansion of the models used in the concept selection process 
(E-5) and in ah input to the requirements baseline (A-5) . 

6. Determine General Test Philosophy 

At this point in the development process, after the airborne 
equipment has been essentially determined, that initial thought 
is given to the GSE and facilities required. A general test 
philosophy is determined by the verification discipline of cen- 
tral systems with the participation of the other central systems 
disciplines (B-6) . The general test philosophy developed is based 
on information obtained from the requirements baseline (A-6) , the 
technical disciplines (C-6) , and the system element models (E-6) . 

7 . Definition of GSE and Facility Requirements 

GSE and facility requirements are defined by central systems de- 
sign and integration discipline with participation from airborne 
equipment design, GSE design, and facility design technical disci- 
plines . These definitions are based on the requirements baseline 
data (A-7) and the activities of D-7 . 

8. Determine Ground Systems Initial Concepts 

With the general test philosophy established and the GSE and fa- 
cility requirements defined, the ground systems Initial concepts 
are determined by the GSE and facilities technical disciplines 
(C-8) . The A/B equipment technical disciplines participates in 
the determination of the ground system initial concepts (C-8) . The 
results are input to the requirements baseline (A-8) and the sys- 
tem element line (E-8) . 

9 . Perform Mission Operations Analysis 


Once the GSE and facilities concepts are established, a missions 
operations analysis is performed by the central systems disci- 
plines (B-9) . The material in the requirements baseline (A-9) , 
the information provided by GSE and facilities design (C-9) , and 
the system element concepts and description (E-9) are used as the 
sources of data for the analysis. The activities shown in D-9 are 
the ones involved in the analysis . The results of the mission 
operations analysis are input into the central systems require- 
ments baseline (A-9) . 
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Performance Sizing 


A performance sizing activity of the airborne equipment is con- 
ducted by the airborne equipment technical disciplines (C-10) . 

The source of information used in the performance sizing activity 
is the requirements baseline. The result of this activity is the 
sizing of the airborne systems (E-10) , and the performance sizing 
results are integrated in the requirements baseline. The activ- 
ities of D-10 are involved in the sizing and integration process. 

11. Sizing Integration 

Based on the results of the performance sizing activity, the de- 
sign and integration discipline of central system engineering 
performs an integration activity to assure that the performance 
sizing results are compatible with the total system concept 
(B-ll) . This integration activity must be performed before the 
sizing results are integrated in the requirements and definition 
baseline (A-ll) . 

12. Perform Operations Sizing 

An operations sizing analysis is performed by the central systems 
engineering and technical disciplines (B-12 and C-12) using, as 
the basis for the analysis, the source material contained in the 
requirements and definition baseline and information from the 
system element (E-12) . The activities of D-12 are involved and 
result in the determination of the personnel required for ground 
operations (E-12) . The results of the operation are also inte- 
grated in the requirements and definition baseline. 

13. A/B Equipment Design Definition 

The activities of D-13 are performed during the design definition. 
The source material for the design definition activity came from 
the requirements definition baseline (B-13) and the system ele- 
ments (E-13) . The outputs of the airborne equipment design def- 
inition result in the airborne equipment being defined (E-13) and 
integrated in the baseline (A-13) . 

14. Perform Systems Review 

After the airborne equipment is defined, a systems review is held 
to determfine if the equipment, as defined, meets all require- 
ments. The requirements and definition baseline (B-14) is the 
source of information for the systems review. The results of the 
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systems review are integrated in the system elements (E-14) and 
in the requirements and definition baseline (A- 14) for use in 
subsequent definition update. 

15. GSE and Facility Concept Definition 

After the systems review of the airborne equipment, the GSE and 
facility concepts are fully defined (C-15) so that selection can 
be made. 

16. GSE and Facility Concept Evaluation & Selection 

Once the alternative concepts have been fully defined, they are 
evaluated by central systems engineering and the best concepts 
selected (B-16) . The activities of D-16 are involved in the 
evaluation and selection process. This activity results in GSE 
and facility system element concept selection (E-16) , and the 
results are integrated in the requirements and definition base- 
line. 

17. GSE & Facility Performance Design Analysis 

A performance design analysis is conducted by GSE and facility 
technical disciplines (C-17) concurrently with an integration 
activity performed by the central systems disciplines (B-17) . 

The basis for these activities is the requirements contained in 
the requirements and definition baseline (A-17) . The output of 
the performance design analysis is input into the baseline (A-17) 
and the expanded concept models (E-17) . The activities of D-17 
are performed in the process. 

18. GSE & Facility Performance Sizing 

Performance sizing of GSE and facility equipment is performed by 
GSE and facility technical disciplines using the activities of 
D-18. The information source for the activity is that contained 
in the central systems requirements and definition baseline (A-18) . 
The output of the performance sizing operation is integration in 
the baseline (A-18) . Concurrently with the performance sizing 
operation, an integration activity is performed by central sys- 
tems to assure compatibility of the results of the performance 
sizing activity with the total system (B-18) . The output of the 
performance sizing and integration activities results in the siz- 
ing of GSE and facility systems elements. 
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GSE and Facilities Design Definition 


Subsequent to the performance sizing of GSE and facilities, def- 
inition of the design of these elements occurs (C-19) resulting 
in system element definition (E-19) which is integrated in the 
requirements and definition baseline (A-19) . 

20. A/B Equipment Design Definition Update 

After the GSE and facility design has been defined, the airborne 
equipment technical disciplines perform a definition update of 
the airborne equipment (C-20) resulting in an update of the pre- 
viously defined airborne equipment (E-20) . The results of this 
activity are integrated in the requirements and definition base- 
line (A-20). 

21. Operations Update 

After the airborne equipment definition update and the GSE and 
facility definition, an update of the total system operation is 
performed (B-21) assuring that the system elements, as defined, 
are compatible with the total system. Information for this up- 
date comes from the requirements and definition baseline (A-21) 
and the system elements (E-21) . The output of the operations 
update activity is integrated in the requirements and definition 
baseline (A-21) . 

22. Requirements and Definition Review 

A requirements and definition review is held by central systems 
engineering to assure that the systems elements, as defined, and 
the operations concepts as updated, will meet the total system 
performance and definition requirements (B-22) . All activities 
that have occurred prior to this point in time and the require- 
ments contained in the central system integrated requirements 
and definition baseline form the basis for this review. Approval 
of all activities prior to this point in the development process 
results in approved airborne and ground system element definition 
(E-22) and sets the stage for the design phase that follows. 
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APPENDIX 


1. SCOPE 

This document defines mission and system criteria necessary for 
the definition of individual subsystem elements. This criteria 
is a directive to all products (subsystems) and functional (ve- 
hicle performance, reliability, safety, logistics, etc) disci- 
plines for specification and hardware development. 

2. APPLICABLE DOCUMENTS 

3. REQUIREMENTS 

3.1 Program Definition 

3.1.1 General Description 

3. 1.1.1 Airborne Items 

3. 1.1. 2 Operation Ground Support Equipment 

3. 1.1. 3 Facilities 

3. 1.1. 4 GFE 

3.1.2 Missions 

3.1. 2.1 Launch Rates 

3. 1.2. 2 Launch Risks 

3. 1.2. 3 Hold Requirements 

3. 1.2. 4 Launch Date 

3. 1.2. 5 Launch on Time 

3.1. 2. 6 Launch Window 

3. 1.2. 7 Reaction Time 

3. 1.2. 8 Payload Description - Crew, Type, Size, and Weight; 
Instrumentation Type, Size, and Weight 
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3.1.3 Operational Concepts 

3. 1.3. 2 Flight Duration 

3. 1.3. 3 Maneuvers 

3. 1.3. 4 Recovery (Data or System) 

3. 1.3. 5 Mission States 

3. 1.3. 6 Baseline Reference Flight Path Trajectory 

3.1.4 Organizational and Management Relationships 

3.1.5 Systems Engineering Requirements 

3.1.6 GFP 

3.1.7 Critical Components 

3.2 Characteristics 

3.2.1 Performance 

3.2.2 Physical 

3.2.3 Reliability 

3. 2. 3.1 System Reliability (Failure Modes, Redundancy, Useful Life) 

3.2.3. 2 Reliability, Apportionment to System Elements 

3.2.4 Maintainability 

3. 2. 4.1 Maintainability 

3. 2.4. 2 Maintainability Downtime Allocations to System Elements 

3.2.5 Operational Availability 

3.2.6 Safety 

3. 2. 6.1 System Safety 

3.2.7 Environment 
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3.2.8 Transportability/Transportation 

3.2.9 Storage 

3.3 Design and Construction Standards 

3.3.1 Selection of Specifications and Standards 

3.3.2 General 

3. 3. 2.1 Electromagnetic Interference Requirements 

3. 3. 2. 2 Man/Machine Requirements 

3.3.3 Design Standards 

3.3.4 Moisture and Fungus Resistance 

3.3.5 Corrosion of Metal Parts 

3.3.6 Contamination Control 

3.3.7 Coordinate Systems 

3.3.8 Interchangeability and Replaceability 

3.3.9 Identification and Marking 

3.3.10 Workmanship 

3.3.11 Human Performance/Human Engineering 

3.3.12 Computer Programming 

3.4 Logistics 

3.4.1 Maintenance 

3.4.2 Supply 

3.4.3 Facilities and Facility Equipment 

3.5 Personnel and Training 

3.6 Interface Requirements 

3.6.1 Intraprogram Interface Requirements 
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3. 6. 1.1 Vehicle/Ground Interface Concept Criteria 

Criteria must be defined to allow design definition of 
ground systems that will operate and mate compatibly. 

3. 6. 1.1.1 Umbilicals 

3. 6. 1.1. 1.1 Location Constraints 

3. 6. 1.1. 1.2 Separation Requirements 

3. 6. 1.1. 1.3 Type-manned, Fly-away, Remote 

3. 6. 1.1. 2 Checkout Criteria 

3. 6. 1.1. 2.1 Subsystem Checkout Requirements 

3. 6. 1.1. 2. 2 Integrated System Checkout Requirements 

3. 6. 1.1. 2. 3 Malfunction Detection Requirements 
3. 6. 1.1. 2. A Countdown Requirements 

3. 6. 1.1. 2. 5 Inflight Checkout Requirements 

3.6.1. 1.3 Hold Criteria 

3. 6. 1.1. 4 Shutdown (kill) Criteria 

3. 6. 1.1. 5 Signal Interfaces 

3. 6. 1.1. 6 Facility Requirements 

3.6.2 Intraproject Interface Requirements 

3.7 Requirements for Program Elements 

3.7.1 Facilities 

3. 7.1.1 Location of Operational Installation 

3. 7. 1.2 Location of Special Test Installations 

3. 7. 1.3 Ambient Environments at Installations 

3. 7.1.4 Test Range and Support Systems Ground Rules and Assumptions 

3.7.2 Vehicle Design Criteria 

Criteria for the following items must be developed for an 
airborne flight vehicle or payload. 
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3 . 7 . 2.1 


3 . 7 . 2. 2 

3 . 7 . 2 . 2.1 

3 . 7 . 2 . 2. 2 

3 . 7 . 2 . 2. 3 

3 . 7 . 2. 3 

3 . 7 . 2 . 3.1 

3 . 7 . 2 . 3. 2 

3 . 7 . 2 . 3. 3 

3 . 7 . 2 . 3. 4 

3 . 7 . 2 . 3. 5 

3 . 7 . 2 . 3. 6 

3 . 7 . 2 . 3. 7 

3 . 7 . 2 . 3. 8 

3 . 7 . 2 . 3. 9 

3 . 7 . 2 . 3.10 

3 . 7 . 2 . 3.11 

3 . 7 . 2 . 3.12 

3 . 7 . 2 . 3.13 

3 . 7 . 2 . 3.14 
• 3 . 7 . 2 . 3.15 


System Concept Description 

The fundamental concept of each system element selected dur- 
ing concept feasibility phase is defined and described. For 
example, concept studies may establish a basic vehicle type 
and configuration — number of stages, use of an existing en- 
gine, booster, or facility, etc. 

Reliability Requirements 

Design Goals and Mission Success Requirements 

Launch on Time Requirements 

Allocations to System Elements 

Performance Requirements 

Payload Capability 

Mission Capability 

Maneuvering Requirements 

Accuracy Requirements 

Expected Life 

Reaction Time 

Ptopulsion Systems 

Guidance Systems 

Flight Safety Systems 

Manfunction Detection Systems 

Life Support Systems 

Structures 

Electrical Power Systems 

Attitude and Velocity Correction Systems 

Hydraulic Systems 


127 


3 . 7 . 2 . 3.16 


3 . 7 . 2 . 3.17 


3 . 7 . 2 . 3.18 


3 . 7 . 2. 4 


3 . 7 . 2 . 4.1 


3 . 7 . 2 . 4. 2 


3 . 7 . 2 . 4. 3 


3 . 7 . 2 . 4. 4 


3 . 7 . 2. 5 

3 . 7 . 2 . 5.1 

3 . 7 . 2 . 5. 2 

3 . 7 . 2 . 5. 3 

3 . 7 . 2 . 5. 4 

3 . 7 . 2 . 5. 5 


3 . 7 . 2. 6 


3 . 7 . 2 . 6.1 


3 . 7 . 2 . 6. 2 


3 . 7 . 2 . 6. 3 


3 . 7 . 2 . 6.4 


3 . 7 . 2 . 6 . 4.1 


3 . 7 . 2 . 6 . 4. 2 


3 . 7 . 2 . 6 . 4. 3 


3 . 7 . 2 . 6 . 4. 4 


Gas Systems 
Fluid Systems 
Ordnance Systems 
Performance Allocations 
System Element Allocations 
Weight Allocations 
Error Allocations 
Risk Allocations 

Interface Criteria System, Element to System Element 

Performance 

Functional 

Physical (mechanical and electrical) 

Signal 

Man/Machine 

Loads Criteria 

Launch Loads 

Prelaunch Loads 

Transportation Loads 

Inflight Loads 

Aerodynamic 

Maneuvering 

Acceleration 

Staging 
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3. 7. 2. 6. 4. 5 

Nonaerodynamic Pressures 

3. 7. 2. 7 

Transportation Requirements 

3. 7. 2. 7.1 

Factory to Launch Site 

3. 7. 2. 7. 2 

Assembly 

3. 7. 2. 7.3 

To Stand 

3. 7. 2. 8 

Storage Requirements 

3. 7. 2. 8.1 

Environment 

3. 7. 2. 8. 2 

Location 

3. 7. 2. 8. 3 

Duration 

3. 7. 2. 9 

Checkout Concept 

3. 7. 2. 9.1 

Factory 

3. 7. 2. 9. 2 

Assembly 

3. 7. 2. 9. 3 

Readiness 

3. 7. 2. 9. 4 

Launch 

3. 7. 2. 9. 5 

Inflight 

3.7.3 

Ground System Concept and Requirements 

3. 7. 3.1 

Performance Goals for Checkout Systems 

3. 7. 3. 1.1 

Vehicle Verification Systems 

O -1 O 1 O 

J* / . J . X . X 

Launch Control Systems 

3. 7.3. 1.3 

Launch Monitoring Systems 

3. 7. 3. 1.4 

Malfunction Detection Systems 

3. 7. 3. 1.5 

Malfunction Isolation Systems 

3. 7. 3. 1.6 

Data Acquisition Systems 
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3.7.3. 1.7 

Subsystem Checkout Systems 

3. 7.3. 2 

Performance Requirements for Support Systems 

3. 7. 3. 2.1 

Propellant Servicing Units 

3. 7. 3. 2. 2 

Water Systems 

3. 7. 3. 2. 3 

Gas Systems 

3. 7. 3. 2. 4 

Hydraulic Systems 

3. 7.3. 2. 5 

Environmental Control Systems 

3. 7. 3. 2. 6 

Electrical Systems 

3. 7.3. 2. 7 

Air Conditioning Systems 

3. 7. 3. 2. 8 

Communications Systems 

3. 7. 3. 2. 9 

Tracking Systems 

3.7.3.2.10 

Handling Equipment 

3. 7. 3. 3 

Performance Requirements for Facilities 

3. 7. 3. 3.1 

Fabrication Facilities 

3. 7. 3. 3. 2 

Acceptance Facilities 

3. 7. 3. 3. 3 

Test Facilities 

3. 7. 3. 3. 4 

Support Facilities 

3. 7. 3. 3. 5 

Training Facilities 

3. 7.3.3. 6 

Launch Facilities 

3. 7.3.3. 7 

Recovery Facilities 

3. 7.3.4 

Reliability Requirements 

3. 7. 3. 4.1 

Design Goals and Mission Success Requirements 

3. 7. 3. 4. 2 

Launch on Time Requirements 
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3. 7.3. 4. 3 

Allocations to System Elements 

3. 7. 3. 5 

Maintainability Requirements 

3. 7. 3. 5.1 

Design Goals 

3. 7. 3. 5. 2 

Downtime Allocations 

3. 7. 3. 6 

Interface Criteria - System Element to System Element 

3. 7. 3. 6.1 

Performance 

3. 7. 3. 6. 2 

Functional 

3. 7.3. 6. 3 

Physical (mechanical and electrical) 

3. 7. 3. 6. 4 

Signal 

3. 7. 3. 6. 5 

Man/Machine 

3. 7. 3. 7 

Safety Requirements 

3. 7. 3. 8 

Environmental Requirements 
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